I don’t like people telling me how to do my job. I never have. I think of writing code like making music. To me, writing code is an artform. Do artists like to be told how to art? Nope. Well, then why would it be okay to tell a developer how to write code? I’ll be showing you why coding standards exist, what they are and are not, and how they can release the true creative you!

The idea of a standard used to be this image I would see in my head where there was a cop handing me a ticket because I was going to fast and not obeying the law (standard). I don’t know why that was the picture I got, but it was. What do you think of when you hear that word? Some think about it in a positive way and others see it in a negative way. I know that American Standard toilets are some high quality toilets. I also know that there are standard pillows and standard cars. Hmmm, does standard kind of mean “the same”? Let me check… 

Yes, I actually did just google that. So I guess it’s not all bad then, it just means “average” in a way. Is that what standards are for? To make things average? “I thought you said standards can release the creativity I neeeeed!”, said the person reading this, shaking a finger in the air, “Now you’re telling me they will make me average!?”. You are right, both ways.

Having a standard way of doing something does not have to inhibit your ability solve a problem in software development in your own way. Having a standard way of doing something can actually simplify the everyday details like using tabs or spaces for indentation or what style of brackets to use. Standards can also protect you from falling into common traps. Standards, when used for good, can set you free to focus on solving the problem and not getting worn out from tons of micro-decisions.

What Are Standards?

I like to think of standards as an agreed upon ruleset that helps define best practices in development. Standards can be applied to languages, frameworks, system design, and even how you interact with your team members. Some standards are are in areas of the “look” of the code, while others are considered more of a “Best Practice”:

• Indentation
• Naming and Casings
• Bracket Style
• Code Structure
• Design Patterns 

In my opinion, for something to be considered a standard, it must be for a reason and it should never be set in stone. Standards can and should change over time, across languages, in different industries, etc.

Why Do We Need Them?

I want to give an example of something I’ve seen over and over again. Let’s say you just started your new job at TechCo and you finally get to sit down and start working on solving a problem by writing some code. Now, since you are joining an existing company, you are most likely working on some existing code-base. When you find the spot(s) you need to change, how do you change them? Do you just make the change in anyway you feel like? Do you look at the code around you and try to emulate what it looks like? I’ll just say you made the best choice you could make and called it done.

Most companies will have others review the code you write. In this example, Dave, the Senior Developer takes a look at your code and starts making comments about this and that and why that was a dumb idea, etc. Now, you’re defeated, you solved the problem, but you didn’t solve it the way that Dave would have solved it. You make the changes he wanted, resubmitted them, closed your laptop, and went to your car for a good scream or cry or whatever.

A lot of developers have a really bad first “coding” day. Having standards can protect new developers on their first “coding” day. When used right, standards can be used in reviews to help mentor developers by showing them a guide that explains why, in this case, Dave was all over your code. If TechCo had a standards guide, Dave could and should have pointed you to those before you wrote your first line of code and if anything was found during his review. Standards can create a win-win situation when used for the purpose of good.

Some people may believe the idea of standards is just a way to force developers to write code that looks like it was written by a single developer. Standards are not meant to dictate you. They are meant to ease the annoying pieces of coding, such as naming things, and struggling over where to put pieces of code. It’s better to think of standards as Best Practices. They are more of a guide that helps lead developers in a common, well-known direction. As a guide, it should help navigate around potential pitfalls that could lead to bugs. It should clear up the minutiae. It should help clean the code and make it more readable.

Example

Here is an example of a standard that can help prevent future bugs:

if(isDebugMode())
  write(mySecretCode);

write("Enter your password:");

The code above will help the person debugging the code know what the password is if they are in debug mode. But what if someone decides someday that they want to comment out the portion that writes the secret:

if(isDebugMode()) 
  //write(mySecretCode); 

write("Enter your password:");

Now the code, in some languages, will only write the “Enter your password:” part if they are in debug mode. Well now, that’s probably not a good thing. What if we had a standard that said we always need to use brackets. What happens now:

if(isDebugMode()) {
  //write(mySecretCode); 
}

write("Enter your password:");

Now, adding the comment doesn’t have any side effects! Yay! Standards!!!

If you’re interested in seeing examples of standards, check the links below:

https://github.com/devsplained/opinionated-csharp-standards
https://angular.io/guide/styleguide
http://google.github.io/styleguide/