About coding style guides


Coding style guides, like in “there should be one and only one whitespace before an opening bracket” are bad, and if you enforce them, you should feel bad. And kittens will die.

The longer version

Yesterday, when I was working on an Android codebase (yeah, I know, me doing Java, haha LOL), a build failed because I did not add a whitespace after a comma.

Well, that’s hardly worth a blog post, you might say. And you might be right. But the thing is, I think it is time to stop this craziness.

Style guides. Why?

Well, if you ask anyone that really believes in the benefits of enforcing a strict coding style, he would probably say standards are good because:

  1. A strict style makes code consistent. If different developers follow a common style, the code will always look the same, no matter who wrote it. Which leads to:
  2. A strict style guide enforces collective ownership of the code. You should not be able to tell who wrote a particular piece of code by just looking at it, by just checking the style. Which means, in a way, that if can not be attributes to a specific developer, if will be attributes to “the team”
  3. A strict style guide avoids meaningless diffs in pull requests. Like when, for example, someone adds an empty line before a return statement because of muscle memory.

Style guides. Really!?

Well, if you ask me, thought, my answer would be: I don’t want to work in a place that enforces following a 10 pages long style guide.

If a developer wants to write Egyptian brackets, while another developer needs to see the brackets in the next line… why should that be forbidden? What’s the benefit?

  1. Why is consistency so important? What makes code hard or easy to read is the intrinsic simplicity of it, not whitespacing. Unnecessary loops, poorly named variables, long methods with multiple responsibilities… those are some of the things that make code hard to read and understand. Not a whitespace after a comma.
  2. Even with a strict stye guide, you are going to be able to tell who wrote what parts of the code. If you know your team, and you don’t know to know your team that well for this, you will just know.
  3. Collective code ownership is not enforced by a style guide. Collective code ownership is an attitude, that people have or do not have. You, as a team lead, can do lots to build a team where everyone cares about the overall code quality, and everyone sees the final product as a collective effort, and no one tries to bale anyone else for bugs or defects or lower quality code. Creating that environment is your job, not a stye guide’s job.
  4. Yeah, inadvertent diffs. Mmmmmmmkay, I give you that one. I don’t think it really matters, but I give you that one. If avoiding those is so important to you and your team’s health, then automate the process. There are IDEs, plugins, scripts, all kinds of tools to enforce your beloved whitespacing. Just let those tools do their job.

I don’t think that word means what you think it means

This is what I hear when someone enumerates the benefits of strict style guides: “I want to micromanage every single aspect of your work”.

I don’t want to work for dictators. I don’t want to become one. Write your brackets wherever you want.

Leave a Reply

Your email address will not be published. Required fields are marked *