Is good code style always subjective?
During my professional years, I have taken part in quite a few discussions about code format and code style. Usually, everybody is almost overly enthusiastic about discussing code formats. Then the discussions get intense and oftentimes emotional quite quickly until it hits the point of no return. The discussion is deadlocked — you can be almost certain that you cannot find any sort of agreement anymore. “Do I put braces in the same line as the function or the next line” — everybody has an opinion on that, and rarely anybody changes his/hers. As much as I care about code format I always struggled with the process itself. It always felt way too subjective.
Recently I discussed this with a colleague. He responded: “It’s easy. All our styling rule changes should make the git-diff better.” So simple, yet mind-blowing. That sounded like the solution to my struggles: to formulate a goal against which all styling rule changes can be validated — objectively.
If you talk about what you want to accomplish with a specific code format the discussion is elevated to a whole new level. Even though the process of finding those goals can be tough, I feel it’s definitely worthwhile. The following discussion about which formatting rules to apply is much more objective. It’s as simple as “does this change help us getting closer to our goals”. With this in mind, the discussion can be intense and passionate, but less subjective and very rarely emotional. So how could those goals look like:
Diff-Friendly
If your process heavily relies on code-reviews, or you find yourself digging through the history of your code to understand why certain changes have been applied, you could benefit from changing your code format to make it really diff-friendly.
Consider the following example:
One code format enforces that every Javascript import from the same file is in a separate line, where the other code format enforces imports being one-liners.
You could argue that this still doesn’t make a big difference in diff-friendliness, but if you annotate (aka blame) the file, the different result is even more apparent:
Although you might dislike multiline-imports in JavaScript, I assume that you would still agree that this would make the diff easier to understand. And if making the diffs easy is something that’s important to you and your team you may be more likely to incorporate this rule into your set formatting rules.
Take another example
One code format enforces parenthesis for JavaScript arrow functions even if its a single argument, and the second one doesn’t. Keep in mind that parenthesis for single argument arrow functions are not required. Take a look at the diff, when you add a second parameter to the arrow function.
Also here I would argue that the diff of the first version is a lot cleaner than the second one. So you find parenthesis for single-argument arrow functions in JavaScript unnecessary, but again if making the diff better is a priority for your code-style, then adding this to your styling rules could make sense.
But this should not be a case for specific code styles, nor should it be a case for adjusting your code style to make it more diff friendly. It could however give you an idea of how to objectify, an otherwise most likely subjective discussion about code style.
On a side note: I’ve tried to figure out what the design goals behind popular code formatting guides like Google’s Java Style Guide, Oracle’s Code Conventions for Java or the AirBnB Javascript Styleguide are, but I was unable to find them. I think users could make a much more educated decision, why they would e.g. choose Google’s style guide over Oracle’s Code Conventions, if they knew what the design goals for those style guides are.
