Code Standard and its benefits

It is a fact of life -- developers like to write code in different styles. Show us code written by ten different developers and we can show you ten different coding styles. So why should we try to develop and enforce coding standards? – Nigel Cheshire and Richard Sharpe

Motivation

This week after coming back from vacation and reviewing some code I notice that although we, as a company, advocate code standards people still value “the so called speed” for code clarity and style.

That motivated me to write about the importance of code standard and the benefits the group gains if everyone adhered to it.

Introduction

Believe or not I still remember the time we programmed C in Unix and the pride we would take in knowing that we were the only ones to understand our own code (at least understand while we were working on it). Variables with obscure names (a1, c4, etc) added to the mystic of being a computer scientist.

Nowadays with the improvement of internet, communication, collaboration and other buzzwords that implies working together; code standards became a necessity; a tool to improve communication. The value is no longer in the mystic but code in such an elegant way that the code communicates.

So, why code standards? Code standards are important for many reasons. First and foremost, they specify a common format for source code and comments. This allows developers to easily share code, and the ideas expressed within the code and comments, between each other. Most importantly, a well designed standard will also detail how certain code should be written, not just how it look on screen.

More important than the reasons for having a standard is actually adhering to it consistently.  Having a coding standard documented and available means nothing if developers are not using it consistently.  If that becomes the case, it is no longer a coding standard, it has become a coding suggestion.  Worse yet are the developers that do not have a style or standard at all, and think that their lack of a style/standard IS a coding style/standard!

Style vs. Standard

It is important to differentiate between a style of coding and a standard. A code style specifies things like how you indent, tabs vs. spaces, use of “Hungarian” notation of names and variables, etc. A standard often includes a coding style, but goes beyond just hot to name a variable: it tells you how that variable should be treated and when it should (and should not be) used.

So it is clear that creating a standard is no easy task. Good news is that for us .NET programmers, the standard already exists and tools to enforce these standards are part of the Develop environment we use.

• StyleCop - StyleCop analyzes C# source code to enforce a set of style and consistency rules. It can be run from inside of Visual Studio or integrated into an MSBuild project.
• FxCop or Microsoft code Analyses -FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements. Many of the issues concern violations of the programming and design rules set forth in the Design Guidelines for Class Library Developers, which are the Microsoft guidelines for writing robust and easily maintainable code by using the .NET Framework.

These tools tend to be a pain, initially, when the programmer has so many bad habits that he/she will spend more time fixing their mistakes than coding. But as you become familiar to the standard you start to create good habits and program to the standard.

I personally tend to create snippets, little tools that helps me even more to code to the standard. Nowadays I know exactly what StyleCop will complain if I do wrong.

So what are the benefits you gain by adhering to a standard?

Benefits for Developers

• The source code will be more comprehensive and will become more easy-to-maintain. As the programmers become familiar to the standard and use the supporting tools more and more they tend to program to the standard and produce better code.
• The uniform approach for solving problems will be handy because code standards documents reveal recommended methods that were tried and tested on early projects.
• Less communication between developers and managers will be needed because programmers will not ask anymore on the details of the specification document because the defaults are stated in the standard.
• Is common to the less experience programmer to re-invent the wheel. When there are coding standards, there is a big chance that particular problem is not really a new problem, but in fact, a solution may be documented before.

Benefits for the Quality Assurance Team

• Well documented coding standards will aid the creation of "Test Scripts". Having reviewed the source code and tested an application based on compliance to coding standards, it added strong direction to ensure quality of the software product.
• Of course the readability of code improves QA understanding of functionality what improves the creation of automation or test scripts.

Benefits for Program Managers

• It is important for the project managers to maintain and secure source code quality on their projects. Implementing coding standards could jumpstart this goal halfway to its realization.
• Repeated performance pitfalls could be avoided. It is a common case that a released software product could be less impressive when it comes to performance when the real data has been loaded in the new developed database application.
• Lesser man-hour consumption as the sum of all efforts implementing coding standards.

Adhering to Code Standard

As shown above adhering to a well designed code standard can give your software development an edge. The hard part is convincing developers to adhere to it. Often we hear from developers that adhering to a standard slows them down, the tool is too restrictive, standards take the “creativity” out of programming, etc.

It is understandable that in crunch time you could argue that. It is understandable but not excusable. Tools and techniques are out there to facilitate such techniques. Not adhering to it shows the lack of commitment and the desire to improve.

While I am not going to describe the various methods that can be used to achieve this goal, I will mention one: Accountability.

Accountability will generally cause developers to write better code.  If they wrote a bug, they should fix it.  If the bug would have been prevented by adhering to the standard, it should be brought to their attention.  The flip side of this is that they should be rewarded for writing good code.

The secret to code to a standard is to constantly use stylecop or other tools. You may be impacted initially but it will payoff for you and your team later.

Conclusion

Coding standards are being adopted by more and more development organizations. Estimates suggest that 80% of the total cost of a piece of software goes into maintenance, and not enough effort is being directed at ensuring that the quality is maintained during the development process. Further, development and Quality Assurance teams are spending too much time in code reviews, correcting coding standards violations that could be detected and in some cases corrected automatically.

Tool for code analyses and coding style are out there to help achieve this goals. The challenge is not in the technology but in educating developers on the benefits of adhering to it.