4 ms·

As lots of us know from experience, it's very ver hard to get an in-production project into a warning free state with warnings at maximum and warnings as error

by jahnu 5y ago

As lots of us know from experience, it's very ver hard to get an in-production project into a warning free state with warnings at maximum and warnings as errors. I'm currently working on a new project this year and it has been such a joy to have near max compiler warnings as errors with multiple compilers (and clang tidy and clang format) right from the start.

IanSanders 5y ago
Warning definitions also change over time with new versions
stinos 5y ago
it's very ver hard to get an in-production project True, especially for older projects which never cared about warnings to begin with. Still when I encounter one I might try it anyway, gradually if possible, to see what comes out. Not just because it is indeed just joy to have no warnings, but also because more often than not some of those warnings actually tell you there are bugs. Or for example (just had this last week) because there are projects which compile with 10k+ warnings which mean that even if you just compile a single file, it is way to hard to tell whether your new code just introduced a new warning and if so which one it is.
- jahnu 5y ago
  Absolutely. One strategy I employed with a very old code base with a gajillion warnings was to output them to a file and compare against a reference file at the end of the build. If the output changed we would fix those and maybe any that kept happening if you added new compilation units etc. It at least helped us slowly reverse the trend of accumulating warnings.
  - lelanthran 5y ago
    I did the same, but it meant that the build could not go in parallel. I also stored the warnings.txt in git so that before any commit I could simply do a git diff to see what warnings were changed by my additions.
AndreyKarpov 5y ago
Integration of a static analyzer into an existing project may be hard. Especially if the project is big and old. In fact, it’s not as scary as it seems to be. There are ways to do it as easy as possible: How to introduce a static code analyzer in a legacy project and not to discourage the team - https://pvs-studio.com/en/blog/posts/0743/ https://pvs-studio.com/en/blog/posts/0743/

by jahnu 5y ago

IanSanders 5y ago

Warning definitions also change over time with new versions

stinos 5y ago

it's very ver hard to get an in-production project True, especially for older projects which never cared about warnings to begin with. Still when I encounter one I might try it anyway, gradually if possible, to see what comes out. Not just because it is indeed just joy to have no warnings, but also because more often than not some of those warnings actually tell you there are bugs. Or for example (just had this last week) because there are projects which compile with 10k+ warnings which mean that even if you just compile a single file, it is way to hard to tell whether your new code just introduced a new warning and if so which one it is.

jahnu 5y ago
Absolutely. One strategy I employed with a very old code base with a gajillion warnings was to output them to a file and compare against a reference file at the end of the build. If the output changed we would fix those and maybe any that kept happening if you added new compilation units etc. It at least helped us slowly reverse the trend of accumulating warnings.
- lelanthran 5y ago
  I did the same, but it meant that the build could not go in parallel. I also stored the warnings.txt in git so that before any commit I could simply do a git diff to see what warnings were changed by my additions.

AndreyKarpov 5y ago

Integration of a static analyzer into an existing project may be hard. Especially if the project is big and old. In fact, it’s not as scary as it seems to be. There are ways to do it as easy as possible: How to introduce a static code analyzer in a legacy project and not to discourage the team - https://pvs-studio.com/en/blog/posts/0743/ https://pvs-studio.com/en/blog/posts/0743/