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:
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:
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:
Take another example
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.