On 12/4/2017 8:58 PM, Stefaan Dutry wrote: > Talking from my personal experience, you should not just blindly > eliminate all Issues reported by a code analyzer. > (I've done that for a single project at our work and i've regretted it > ever since) > > My advise would be to start with the things: > -) that are in the section of a file you're working on > -) that seem logical > -) that don't decrease readability > -) that don't increases complexity (interpreted by humans, not a code > analyzer). > > And when fixing one: > -) use a seperate commit > -) with a clear message
Thanks! Yes I agree. Specially with "that are in the section of a file you're working on". As you may saw, I disused Sonar's GitHub plugin which can analyze PRs and would help a lot to avoid making things worse. I also will work if `coverall` can warn on PRs if a changed or added file has coverage less than e.g. 85%. This helps a lot both Pull Requester and Reviewers. Pull Requester will know tests should be added. Reviewer will know this PR should be reviewed more carefully. Thanks for your attention, Yasser.
