Does your team use a coding standard? If the answer is no, then I’m afraid you’re missing out on a lot of important benefits. This post will help you create (and automate) C# coding standards using Submain’s CodeIt.Right. I’ll start out by making the case that you need a coding standard. We here at the SubMain blog have already covered that subject, of course, but I’ll revisit it anyway.
With that out of the way, I’ll go on to explain the most common problems that occur when teams try to implement coding standards and code reviews manually.
Finally, I’ll show you how automation can heal these pains, and how to use CodeIt.Right for doing so. Let’s get started.
C# Coding Standard: What Is It?
Before talking about coding standard, let’s define what we mean by the word “standard” alone. In our post about the importance of a team standard, we make (what I like to think of as) a very good distinction by saying the following:
When I talk about the importance of a standard, I speak with the second flavor of the word in mind. I speak about the team looking at its code with a discerning attitude. Not just any code can make it in here—we have standards.
In our context here, think of standards as a set of quality requirements, or the bare minimum list of demands your team’s work will be held to. With that definition in mind, the phrase “C# coding standards” becomes virtually self-explanatory: it refers to quality requirements that a C# codebase must be held to.
The next question then becomes why should you bother?
C# Coding Standard: What Are the Benefits?
When you ask people why they don’t use a coding standard, they may offer you several valid or less valid reasons. There seems to be a particularly common misconception that a coding standard only deals with cosmetic concerns. While aesthetic concerns do play a role in a coding standard, they certainly don’t play all of them.
What are the true benefits, then? What will you and your team gain by adopting a C# coding standard?
The first obvious benefit of a coding standard (or any standard, come to think of it) is that it creates consistency. If you can look at a piece of code and guess its author, that’s a bad sign. There shouldn’t be such a thing as Bob’s style or Alice’s style of writing code.
Consistency by itself is not enough, though. It’s not a great thing if the code in your application is consistently bad across the board, right? So, a great coding standard should also help you to reduce bugs, by encouraging best practices and patterns that make common errors less likely.
A great coding standard will also facilitate code review. My personal opinion is that the code review is, in general, a better approach to software quality than, say, pair-programming. But there’s no denying that the code review can easily go downhill. I believe most of us have our horror stories to share.
With a coding standard in place, we can remove most of the things that can make a code review practice go toxic. Personal opinions, egos, politics…all of that goes away when you have an authoritative guide people can refer to.
The benefits of a coding standard rapidly start to bear fruit and create even more benefits. Code that is consistent and less error-prone will inevitably make an application that is easier to maintain and add new features.
Consistent code across the team—and even across different teams—will reduce the learning curve for working with the codebase, making it easier to onboard new team members.
A facilitated, drama-free code review will bring all the benefits that code reviews usually bring, but sooner and with less pain.
Here Be Dragons: When Coding Standards Go Wrong
Life isn’t always a bed of roses, right? Things often go wrong when trying to implement a coding standard.
Here are some of the main problems that you might face when implementing a coding standard:
- resistance from team members or management
- disagreement over which rules/guidelines to follow
- lack of enforcement to the standard
- toxicity in the team caused by code reviews anti-patterns
And probably more.
Fortunately, the answer to these problem shouldn’t come as a surprise for a developer.
The answer to many of the challenges you may face when trying to implement a coding standard is to automate the whole thing as much as possible.
By removing the human factor from the equation as much as you possibly can, many of the aforementioned problems simply disappear.
If you start with a default standard and then gradually adjust it, you remove the lack of consensus problem. Since enforcing usage of the standard is automatic, there’s no risk of people forgetting to comply with the standard (or, even worse, deliberately failing to do so).
Implementing Your C# Coding Standard in 3 Steps, With the Help of CodeIt.Right
Ok, folks, it’s finally time to get practical. In this section, I’m going to give step-by-step tips on how to get your C# coding standard up and running with the help of CodeIt.Right.
Step 1—Start With a Default Standard and Customize It If Needed
Don’t get yourself sucked into pointless discussions, such as the position of curly braces, whether or not to add a “_” at the start of every private field member, and so on. These distinctions are, for the most part, arbitrary. At the end of the day, which side of the discussion you pick doesn’t really matter that much, as long as you pick one and stay consistent.
CodeIt.Right helps you by coming pre-packaged by default with the Microsoft coding guidelines. It also offers its own version of the guidelines, called the SubMain .NET coding guidelines document.
You can choose either one as your standard and then customize it according to your team’s needs and preferences. CodeIt.Right lets you tweak the standard by using tools that include creating custom profiles and custom rules.
Step 2—Create a Design Guideline Document, Based on Your C# Coding Standard
Nice. So now you and your team have a coding standard. It’s initiated with a default base and customized to fit your needs. The next step is to use CodeIt.Right to automatically generate a guidelines document for you.
CodeIt.Right will consider your standard to create a document that can be displayed or printed out as you see fit. That way you have a handy manual you can use for whatever you need. For instance, you can use it like a quick reference when a question arises. Or it can be part of your new team-member onboarding kit.
Step 3—Start an Automatic Code Review Process, Powered by CodeIt.Right
There’s a phrase I like to use whenever I need to sell the merits of automation for someone. That sentence is, “Everything that is automatable should be automated.” If you can automate something, then, by all means, do it. That way you can focus on the things that truly benefit from unique human qualities.
With code review, things aren’t different.
The best approach is to aggressively automate the automatable parts of a code review while manually doing the parts that are not. That’s the best of both worlds.
That way, CodeIt.Right will catch errors that people would miss, freeing human reviewers to concentrate on higher-level concerns.
Start Your C# Coding Standard ASAP!
Every software team should work with a coding standard. Period. And with a tool like CodeIt.Right, you’re out of excuses for not doing it ASAP.
When we automate creating and enforcing a coding standard and also a code review, CodeIt.Right removes a lot of the pain that is usually involved in these tasks. What’s left for you and your team is a process of discovery, learning and…maybe even fun. Why not?
Download CodeIt.Right today and start harnessing its power to write better applications.