is it best practice to try to remove ALL compiler warnings with any means [closed]

Question

our project manager recently set up a policy to request developers to remove ALL the compiler warnings. I understand some warnings really are easy to be removed, some are not so easier. So some developers uses every possible way to achieve the goal. For example, using explicit cast to cast double to float, float to int, signed to unsigned etc, etc. Since our code base is so large, over 20 years of 30-50 developers' work, I really doubt that how much this effort can really help us, if it does have some merits. Can anyone give some of your advice or arguments? our project uses C++.

Answer 1

Once you let compiler warnings slip, the 'real' warnings also get ignored as well. I can't count the number of times I've come onto a project with a ton of warnings, that with just a little care, were removed along with a bunch of very subtle bugs. Accidental assignment in an if, accidental fall-through in a switch or no default, accidental ; at the end of a for loop, unintentional type-cast etc. The warnings are there for a reason - use them. Yes, some are very pendantic, but just a little bit of work saves a lot of headache later on.

Clean the warnings and keep them clean. You will write better code.

Answer 2

It can be quite tricky to fix all warnings in a large project. And some compilers have rather obscure sense of "right things to warn for".

It is definitely a good thing to fix warnings. But it should be done the right way - and sometimes, the correct thing is to simply disable that warning.

Some really annoying ones are "unused parameters" - well, if the interface determines that this function is called with two parameters, but you only use one (or none) because for what this particular implementation does isn't using those parameters, then it's hard to fix the warning [you can of course remove the name of the varivable (or put it as a comment)].

Similarly, sometimes compilers can be so picky that it's impossible to be right - I've had cases where not having a return at the bottom of the function gives "not all paths lead to a return" and when I add a return at the bottom of the function, it says "unreachable code" - well, how do you want it? This is where (for that section of code) disabling the relevant warning is the right thing to do.

It gets worse if you have to compile the code with multiple compilers - sometimes what is "good" in compiler, turns into something that is a warning in another, and the fix for that warning turns into a warning in the next compiler, which can be tricky to solve.

Once you have a strategy for coping with warnings, and have removed the ones that you want to remove, disabled the ones you want to disable, I would suggest building your product with "tread warnings as errors".

Most of the time, warnings are "good" for the programmer, and should not be ignored. But there are times when "I know what I'm doing, shut up compiler!" is the right approach - of course, most of the time, those are fixed by applying a cast or some such - and that should be done when it's the right way to fix the problem.