At some point, a code base and the development team that contributes to it will reach a point where standards become a necessity. There are many reasons for implementing coding standards: ensuring merges don’t include unnecessary conflicts, enforcing good practices that aren’t inherent to a programming language and ensuring consistent expectations during code review are just a few reasons.

But implementing code standards is actually a lot harder than it seems. Here are a few tips to make rolling out your own standards easier.

Let Someone Else Do the Work

Companies like Google publicly document their coding standards. In fact, they also publish tools to autoformat code to comply with their standards. Don’t underestimate the value of reusing these standards and tools.

If it is an option for you, adopt the requirements that have already been put into place by people who have already created a set of standards that has proven to be effective.

Plan for Disagreement

Tabs vs spaces. You all know the arguments I’m talking about. Ask 10 developers what their opinion is, and you’ll get 12 different answers.

When it comes to drafting a style guide, arguments like this will bite you every step of the way. If it is not tabs vs. spaces, it is single quotes vs double quotes, camel case vs snake case, self vs me... The list goes on.

If you do choose to draft your own style guide, abandon any expectation that everyone will agree, and adopt some kind of strategy to effectively resolve these arguments. You could take a vote or nominate an arbiter. But have this resolution strategy in place before the arguments get out of control.

Start Small

Too often code standards are dropped like a bombshell, demanding compliance with hundreds of esoteric rules that fail in code that was until recently considered perfectly valid. It is incredibly frustrating to try and accommodate these new rules, and can get to a point where it is so overwhelming that developers will just disable style checking all together.

It is often best to start small by enforcing a limited number of style rules and build from there. Once the practice of verifying code standards becomes part of the development routine, you can start adding more onerous standards.

Don’t Mix Tools

There are dozens of different tools for enforcing coding standards. Your IDE will probably have some style checking built in, while external tools can also be configured to enforce rules. But the various different code style enforces available to you will almost never have the same functionality, and getting them to play nice together just doesn’t work.

Pick one tool and stick with it. Resist the temptation to combine style checkers, because the end result will just frustrate developers and result in code standards being ignored entirely.

Aim to Break the Build

Breaking the build when a code style violation is detected can be harsh and frustrating for developers just trying to get code out the door, but in the long run, it is the most effective and fair way to enforce the rules.

Getting to this point can be hard if you have a lot of existing code that was written before coding standards were introduced, and you may find yourself implementing interim measures like only enforcing standards on new code being committed. But your ultimate goal should be to treat code style violations like any other compiler error and break the build.