Coding style is a vocabulary and a grammar

As professionals, we keep working and refining our craft as we go. We update our standards every now and then so that what we produce is done better.

The first standard to set in place is related to coding style.

Style guides

Coding style is a form of vocabulary and grammar, a dialect your team members must learn and use.

If each team member has her or his own dialect, the code base will become a mix of different styles and become challenging to work with.

To avoid this, a style guide is an essential tool that allows your team to have a reference defining their standard dialect.

Automation

This style guide should not live as a piece of paper pinned to a wall. Instead, it should be directly tied to a piece of tooling (a linter), automatically checking any patch that is pushed into the code base. Humans should not have to worry much about this.

To make it easy on developers: most code editors work well with linters so your team can directly apply the style as they work.

You can also have a brick in your CI pipeline that handles the check and alerts when a change is pushed into the code repository.

I see the CI block as mandatory, the code editor integration as a nice to have.

Evolution

As with all things, that style guide and the relevant pieces of tooling should not be rigid in their use. The team should have the flexibility to review and discuss the style guide, amending it after discovering something is missing, or something isn't fitting how the team works.

Adoption

Setting up a style guide and the tooling at the start of the project should be easy enough: pick a style and go from there (see Evolution above).

It might be tricky if you have a project of some age. Most linting tools have a way to handle a "to-do list", a file listing files to ignore for now. Or you often have the choice to activate linting rules one by one. Thus allowing you to go through your whole code base, one rule at a time.

Conclusion

We think the style and tooling around it are considered incorrectly as a "small thing". We believe it's the basis of an excellent technical culture for software engineers.

We should not have to debate about coding style when reviewing a patch. We should settle any styling questions before getting to work and have a robot ensure the code looks as expected.

Then, regularly, we can have a rational discussion about making those standards evolve. We need to focus and spend most of our time on solving the issues of the users of our product.

If you like this approach, you can join a 2 week cohort based class for Tech Leads and CTOs, you can talk to me during our weekly office hours, or start a multi day assessment with a first introduction call.