Welcome to my first article as a contributing editor for C#. For my first of many weekly articles I'm going to cover coding standards and practices, a topic that is often overlooked.
Define and Publish your C# Coding Standards and Practices
C# coding standards and practices can quickly become hotly debated among developers when they are discussed. I've seen folks go into such a conversation thinking it is a waste of time and getting hotly involved in debate over a particular convention. It is an area where there is rarely a right or wrong, but plenty of opinion. The best advice that I can offer is to make sure you define and document the practices. No matter what they are, identifying what you want to follow is imperative. Once defined, they must be made accessible and communicated to others. This is a great use for a wiki so that others within the organization can contribute.
- Source code structure, layout, and formatting
- Variable naming standards and conventions
- Rules around commenting your code
- Exception handling pattern and process
- Version control and compilation rules
- Expectations around flow control
- Programming patterns that should be applied (or avoided)
- Database related practices
You should document your rules in a clear and concise manner. It is valuable to include a concise coding example that supports the rule, as well as an example that violates a particular rule.
You may also find it useful to break your standards into a series of documents as not all standards and practices apply to all languages. You will likely have some standards and practices specific to the environment if you are an Azure developer, ASP.net developer, C# developer, Visual Basic developer, Windows Mobile developer, WCF developer, ASP.net MVC, Silverlight developer, or programming in C or doing C++ programming. For example, I have standards and practices around use of Session State and View State for ASP.NET applications that would not apply to other types of development.
Enforce Coding Standards and Practices
Coding standards and practices lose their value if not everyone on the team is following them. I've been involved with organizations that do formal code reviews that involve going before a review board of sorts. Those meetings can be very time consuming and tedious. I've also seen a high number of organizations that ignore them altogether as there may be a single developer assigned to a particular project and they are left to their own devices. I employ a mixture of manual as well as automated code reviews. There are great tools like FxCop, which integrates with Visual Studio, and is included in certain versions of Visual Studio. It has rules that can be customized and tailored to your standards. It quickly analyzes your code and reports on findings. This is a great starting point for analyzing code and looking for hotspots. It is also valuable in Visual Studio Team System to use code check-in rules to force developers to run tools on their own code prior to check-in.
The following links point to a couple of sources where you can find some examples of coding standards and practices that I consider to be worthwhile as a starting point:
About the Author:
Mark Strawmyer is a Senior Architect of .NET applications for large and mid-size organizations. Mark is a technology leader with Crowe Horwath LLP in Indianapolis, Indiana. He specializes in architecture, design and development of Microsoft-based solutions. Mark was honored to be named a Microsoft MVP for application development with C# again. You can reach Mark through http://markstrawmyer.com.