Tag Archives: Code Quality

Seven Steps To Quality Code – Introduction

Do you want to reduce the cost of producing your software? Do you want to reduce the number of defects, improve your customer satisfaction and make your developers (or yourself) happier? What about shorten your time to market and improve the speed at which you respond to feature requests? Of course you do! Well, I’m going to outline seven steps that you can take to enable you to achieve all these things.

My view is that software and the software development process can be massively improved by raising the quality of the written code.  What I mean by that, is that I will focus, at least initially, on the code that you see, not necessarily on its functionality.

Now, I’m not claiming that this is an original idea; improving quality is one of the core tenets of most, if not all, of the Agile methodologies, but if you haven’t yet embraced Agile, are struggling with some of the techniques or aren’t seeing the results you expected then the steps I’m going to outline will reap plenty of rewards. The approach could be particularly useful if you are suffering from poor quality code provided by a third party such as contractors or offshore teams.

The Benefits

Going a little further into the benefits of taking the effort to improve your code quality, you can fully expect to see:

    • Reduced costs
    • More reliable software
    • Higher customer satisfaction
    • Quicker response to change requests
    • Quicker response to defects
    • A happier development team

These benefits arise because of:

  • Quite simply – fewer bugs make it into builds
  • Bugs are caught earlier in the development lifecycle (when they are cheaper and easier to fix)
  • Reduced bug counts in system test, acceptance test and in production
  • Reduced time in test – potentially being able to drop a test cycle or two
  • Reduced fix times for any bugs that do occur – but more time to do them in
  • Easier refactoring for improving existing code or adding new features
  • More productive code reviews

The Approach

The approach is based on improving the quality of .Net code. The ideas will be applicable to other languages and environments, but the specific tools that I mention will target .Net and Visual Studio.

The aim is to take small highly practical steps, one at a time, until the end result is a powerful arsenal of tools and techniques that have become an integral part of the way the development team works. Each individual step should not involve any direct costs, the tools I will introduce are free. The only investment required will be a little time, effort and discipline.

The Steps

  1. Compiler Warnings
  2. XML Comments and GhostDoc
  3. Code Analysis – Minimum Rules
  4. StyleCop
  5. Code Analysis – Further Rules
  6. Peer Reviews
  7. Unit Tests

Let’s get started with step 1 – Compiler Warnings

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.