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.
