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
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.
The following list contains common areas that should be
defined within your standards and practices:
- 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
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.