Seven Steps to Quality Code – Step 1

Compiler Warnings

This is step 1 in a series of articles, starting with Seven Steps To Quality Code – Introduction.

I find it staggering how many organisations and how many developers accept and ignore compiler warnings.  If you are one of these people then these incredibly useful messages are your first step in improving your code quality.
Firstly, I know that not everyone is aware of what compiler warnings are, so let me explain.  When the Visual Studio compiler compiles your code, it detects potential problems in the code and produces a list for you to review.  These are problems that do not prevent the code from compiling but do indicate that something should be done to rectify the situation.  You’ll see something like this after compiling:

 

Compiler Warnings
Compiler Warnings after a Successful Build – Click for full size

These two warnings indicate that something is not quite right with your code.  There are a couple of variables that have been declared but never used.  This means, quite simply that you have one of the following two situations:

  1. Some unwanted declarations can be deleted (note that I said DELETED not commented out!).
  2. Visual Studio has caught a bug for you because the variables were supposed to be used.

In either case, responding to the warning appropriately (as opposed to ignoring it) will improve your code.  There are many different types of compiler warning, but they are all telling you something useful about your code.  Read them and act on them!

There is an option in Visual Studio to treat some or all warnings as errors so that if any warnings occur, the build fails. Jan Van Ryswyck in this blog entry takes a hard line and declares that the default setting is “Evil” and that changing the option so that all warnings are treated as errors is “simply none negotiable”.  I’m not going to suggest that you should be quite so strict with the Visual Studio setting, but I agree with the spirit of what is being said.  I allow the freedom to ignore compiler warnings during periods of debugging or ‘spiking’, but compiler warnings should never be  allowed to appear in checked-in code!

The important thing is to adopt a policy where compiler warnings are simply not acceptable.  As I said, I don’t suggest setting Visual Studio to treat errors as warnings, but I absolutely recommend that if you are using automated builds, then the build server is set to fail a build if it encounters any compiler warnings. (If using TFS, this can be achieved easily by adding /p:TreatWarningsAsErrors=true to the MSBUILD command line).

If warnings are not treated as errors by a tool (i.e. Visual Studio or the Build Server), it is critical that the number of warnings is zero.  And that means zero.  Not 1 or 2 or “just a few”, but zero.  There is a theory called Broken Windows Theory  that suggests that if there is a derelict building its windows will stay intact for a certain period time.  When one window gets broken, the others will soon follow suit and the building will deteriorate very quickly.  And so it is with code, once a single compiler warning creeps in, it is then suddenly “OK to ignore warnings” and the code deteriorates.  The bugs that could have been caught in our example above become lost and ignored in a sea of yellow triangles.

In conclusion then, the first step to quality code is a simple one, but an absolutely critical one.  Get rid of all your compiler warnings and take the first step on the journey.  Once you’ve done that, we can move on to step 2.