A well thought trough Check-In Policy can dramatically aid in minimizing bugs and ensuring quality. In the utopian world a check-in policy would be in place before the first line of code is written. In reality most projects ether don’t know what a check-in policy is or don’t see the value it provides.

You can use a check-in policy to catch and correct bugs before the code is checked into your projects source control system. It is generally understood that finding and correcting bugs as early as possible in the development process saves time, money and frustration.

A good check-in policy should ensure that no code is checked in before:
Code compiles without warnings or errors
Unit Tests execute without warnings or errors
Code Analysis executes without warnings or errors

Obviously you should never check in code that compiles with errors, this bring down all the other developers on your team. An area that people often overlook though is warnings, they are generally dismissed as unimportant, something that can be put aside and looked after when there is more time. The problem with that theory is that you never have more time and they are ignored and released into production. Warnings, as the name implies are warnings! They suggest that something “may” go wrong at run time if you do not correct the issue. Again, maybe it will work fine, I don’t know what your warning is about but do you really want to chance it? If you take care of the warnings as they appear it is very easy to keep them at zero. If you ignore them they will grow and reach numbers that are unmanageable and costly in time, money and frustration to correct.

As I described in one of my previous posts, Unit Tests assist you in finding bugs in your code. They are great tools that help you ensure the code is executing as expected, failing as expected and you are not adding changes that adversely effect the functionally related code. Unit Tests can be used to ensure discovered bugs have been corrected and don’t reoccur at a later date. This is all wonderful and helps you write quality applications but what if you ensured that your unit tests were not only run during your scheduled build or during testing? What if you run your unit tests before you checked in your code? You could check in your code with added confidence. The chances of breaking the build, bringing down other developers or increasing the number of test cycles is dramatically reduced.

Code Analysis tools allow you to ensure that you are following the best practices of writing code. Code Analysis tools check how you write your code, not if your code executes to design. It ensures you are adding the appropriate comments, using the proper case for your classes, properties and variables, following recognized globalization techniques and so on. The list is endless and these tools come with a comprehensive list of preconfigured rules. The best part is that you can customize the rules to fit your needs, your companies polices, recognized best practices or whatever. Code Analysis ensures all developers are following a predefined coding standard and increases maintainability of the source code. It can also ensure that you are aligning with business requirements around interoperability, accessibility and other domestic or international standards.

Incorporate these policies early and see the reward with shorter testing cycles, reduced bugs, saved capital and hit targets.