3 ms·

I've worked on systems that had the CI system set up to only fail style or inspection when the overall issue count was larger than the previous one. Over time,

I've worked on systems that had the CI system set up to only fail style or inspection when the overall issue count was larger than the previous one. Over time, your issue count will become asymptotic toward zero. There is a gap in that if you add new code that has issues at the same time that you refactor and remove issues, you won't be alerted. So...don't do that! Tests have also been very helpful. So say I'm in a situation where the legacy code is not style-compliant, let's forget the style-oriented analysis and double down on adding tests. Once you have good test coverage, start to clean up the styling and start to think about static code analysis as part of the build.

shoo 8y ago
> I've worked on systems that had the CI system set up to only fail style or inspection when the overall issue count was larger than the previous one. Over time, your issue count will become asymptotic toward zero. Yeah, that's probably not a bad approach. it also means it is acceptable to introduce new lint violations (this may be unavoidable) if the committer "pays the tax" / "pays a tithe" of fixing some existing violation that might be easier to clean up. another way to implement this (which probably depends upon details of the version control and lint tools being used) is, for each change, query version control to identify what files have changed (or ideally subsections of files), and evaluate before/after lists of issues using the lint tool. for example, for lint tools that only need to read the content of a source file (without e.g. executing or importing it or whatever), and support processing a single file at a time (instead of needing to scan the entire source tree) you can probably cobble something together reasonably easily if no existing tool exists. for example, if you are dealing with a legacy python codebase that is version controlled using git, you could start using `pyflakes` that is able to analyse each file in isolation, and merely needs to read the content of the file and not import or execute it. it isnt that hard to query git to discover which files were changed in a commit (e.g. `git show --name-status <commit>`) or view the content of a file at an arbitrary revision (`git show <commit>:<path/to/file.py>`). with enough glue scripting you could use this to produce a custom report to show what the delta of issues (either a count of sets of the actual specific issues) is for each file touched by a commit, without having to scan the entire codebase.

shoo 8y ago

> I've worked on systems that had the CI system set up to only fail style or inspection when the overall issue count was larger than the previous one. Over time, your issue count will become asymptotic toward zero. Yeah, that's probably not a bad approach. it also means it is acceptable to introduce new lint violations (this may be unavoidable) if the committer "pays the tax" / "pays a tithe" of fixing some existing violation that might be easier to clean up. another way to implement this (which probably depends upon details of the version control and lint tools being used) is, for each change, query version control to identify what files have changed (or ideally subsections of files), and evaluate before/after lists of issues using the lint tool. for example, for lint tools that only need to read the content of a source file (without e.g. executing or importing it or whatever), and support processing a single file at a time (instead of needing to scan the entire source tree) you can probably cobble something together reasonably easily if no existing tool exists. for example, if you are dealing with a legacy python codebase that is version controlled using git, you could start using `pyflakes` that is able to analyse each file in isolation, and merely needs to read the content of the file and not import or execute it. it isnt that hard to query git to discover which files were changed in a commit (e.g. `git show --name-status <commit>`) or view the content of a file at an arbitrary revision (`git show <commit>:<path/to/file.py>`). with enough glue scripting you could use this to produce a custom report to show what the delta of issues (either a count of sets of the actual specific issues) is for each file touched by a commit, without having to scan the entire codebase.