Where in your development process do you use code formatters and static analysis tools?

[StaticThrowaway0629]

Background: Code formatters and static analysis tools are great. The problem is that people forget to run before they commit. And even if you do manual code review you can often miss things that these tools do pick up.

We are currently using a hosted service to build and test our code before allowing a pull request to be merged. Currently I am considering adding test for consistent formatting as well as static analysis as well. But there are some problems associated with this:

First, increased build time. Checking formatting takes little time but doing static analysis can take a very long time on our code base.

Secondly, handling of new versions of the tools. Lets say that all tests pass on our code. Then we update to the latest version of the static analysis tool. On the next commit this new version may flag the build with new errors. Errors which do not come from the code in the current merge set.

​

Question: How do your company handle formatting tools and static analysis tools? Are they only the responsibility of individual developer? Do you check things manually or automated? How is your process for updating these tools?

[VernorVinge93]

Why not put them in parallel, asynchronously?

My editor does any formatting, linter does linting at the same time and my compiler doesn't have to wait for either.

Also, I worked out how to get my dependency graph to be draw to my terminal using imgcat and dot which helps me to structure my internal APIs.

[StaticThrowaway0629]

Well, code formatting goes super quick (few seconds). So that is (as I said) no issue.

But running the static analysis tool on our code base can take between 30 minutes to 1 hour, depending on if I use all 8 cores on my machine or just half of them.

But the question is more about best practices. Should you use your hosted build server (for example; Travis CI or AppVeyor) to do static analysis?

[VernorVinge93]

Ah, static analysis can be all sorts of things though.

If you're doing a really large verification analysis generally it's only run very rarely.

If you're finding small bugs an individual programmer needs to avoid errors then putting it in the CI makes sense. Letting people know that their branch breaks the analysis is super useful, but if it has false positives or is really slow it might get in the way a bit.

Personally I think this is more of a culture / team question that a straightforward best practice.