Code Leader: Using People, Tools, and Processes to Build Successful Software

4.5. No Compiler Warnings

Set your compiler to treat warnings as errors. Before any task can be called done, it should generate no compiler warnings. Warnings are there for a reason, and every warning you eliminate ahead of time is one less potential problem to face later on. It is easy to ignore warnings when you are in the middle of trying to solve a particular coding problem. They can be difficult and time-consuming to track down, and after all, they are just warnings. However, those warnings may represent real issues. Just because code will compile doesn't make it a good idea. Warnings about unreachable code, unused variables, or uninitialized variables may not cause problems today, but they will surely cause problems tomorrow. If they don't turn into actual defects, they will hang around to confuse whoever comes along after you. Remember, you aren't just writing code that you will have to deal with. You are writing code that will be read, modified, and maintained by other developers, possibly for years to come. Every unused local variable is a potential source of confusion for someone who is less familiar with the code than you are.

Improve your code (and your legacy) by getting rid of all the compile warnings. It really doesn't take that much time, and it will make your code easier to read and less likely to exhibit defects later. It is true that there are some warnings that really are spurious. Sometimes you really do know better than the compiler (although not as often ...