Alles Ist In Ordnung

Everything is in order. That's what coding standards are all about. Making sure everything looks right. Especially the ones we have linters for. Correct?

Sort of. Yes, coding standards include formatting and layout. And that's the part linters are best at finding/fixing and annoying us with. And it's important too. Especially in languages that we _mostly_ agnostic to the amount and location of whitespace. Like C/C++. You can pretty much throw spaces and tabs anywhere you want (outside of string literals) and the compiler won't care. Of course taken to the extreme that leads to the obfuscated C contest, and no-one calls that code readable. And that's led to lots of "standards" for formatting.

Golang is similar, in that it doesn't care much about whitespace, but there's also `go fmt` which *will* format your code the correct way, as defined by the language. So you have two options. Do it your own way or do it the official way. Other languages have more rigid spacing requirements. Python makes you pick an indentation for a block and stick with it, but doesn't care what you pick. Some languages let you specify the type for any variable, some have a default type based on the first letter of the variable's name (FORTRAN).

So formatting is kind of arbitrary, but consistency helps us all. Whether it's conventions for variable/method/class/constant names or spacing, indentation, or one-true-brace, the less mental gymnastics you need to go through when you see a new piece of code, the lower the cognitive load, and as mentioned many times, that's a good thing. Especially when your code-base and programming team(s) are large. What works for 5 people doesn't work for 500.

But coding standards are about more than just raw formatting. That's just the most visible part. The meat of standards is really the set of recommendations about how to structure your code. When to use classes, methods, interfaces, libraries, etc. And those are much harder to quantify/lint for. But to me they're even more important. And it goes back to cognitive load. Making things digestible. Making things clear. Being up front about side-effects and possible error cases. Making sure the code clearly identifies the programmers intent.

And that's where it gets hard. Because there are going to be exceptions. And if you've mandated strict adherence to a standard then there's no clean way to express what you want. So how do you handle that?

First and foremost, by making sure the "standards" are recommendations. Very strict recommendations, but not absolute laws. You need to have a good reason to override, but there needs to be a way to silence the linters when needed. Without that things get obfuscated just to placate some code. And we should never let formatting define us.

Second, by making sure everyone knows why the standard includes that rule in the first place. What's it really there for? Is there a better way to achieve that goal than by strictly applying the rule?

Third, by reexamining the standards periodically. Not changing them on a whim, but looking to see which parts are helping, which are hurting, and what areas need better coverage.

Of course, not everyone agrees with me. I've included a link to someone who feels almost entirely the other way around. It's an interesting read, and I encourage all of you to check it out. And then share what you think in the thread. I'll start it off, then go make some popcorn. This should be fun.