Weird Coding Styles¶
I’ve been working in the software industry for 20 years (counting as conservatively as I can) this year, and sometimes people come up with weird styles and enforce them on everyone who touches their codebase. These are a few examples.
Hungarian¶
This is probably the most widely spurned, and also the most popular of the things in this post. Hungarian notation adds type annotations to variable names. But it does it in a secret-code way, and for the literal C type, which the compiler and programmer ought to both know already.
unsigned long ulBadlyNamedVariable;
char *zString;
Joel Spolsky famously wrote a blog post on the distinction between “apps” hungarian and “systems” hungarian at Microsoft. I don’t particularly disagree with his point, but I think what happened was what always happens when there’s a mandatory commenting rule in a coding standard: people start writing useless comments.
Spaces¶
I worked at a company for 6 years whose C style was:
FunctionCall (firstArg, secondArg);
OtherFunction ();
The function and variable naming conventions are fine, I don’t have a problem with TitleCase for functions or snakeCase for variables even though that’s not what I use when left to my own devices. The thing that bugs me is the space between the function’s name and the opening parenthesis.
In fact, at that same job I had one co-worker who advocated (unsuccessfully) for this:
FunctionCall ( firstArg , secondArg );
She thought it was easier to read. Anyway, the justification for the spaces was that in English, there are always spaces before an opening parenthesis. I always thought that was kind of silly, since these are functions and nobody puts spaces around parentheses when writing math.
No Static¶
This may be the single worst example here, because it actually makes
the code less maintainable and more bug-prone. The same company that
mandated hungarian notation (systems-style) also banned the
static keyword. No static variables, no static functions, no use
of the static keyword at all.
The COO of the company seemed to think this made code more debuggable, but I think he had only ever used awful tools or something. I left that company in January of 2008 and I’m still salty about this. Also still traumatized about the time I got yelled at for daring to make a helper function static.
GNU Braces¶
I’ve never had to work at a company that did this, but I use Emacs, and GNU style is the default. This example is taken directly from the GNU coding standard:
if (x < foo (y, z))
haha = bar[4] + 5;
else
{
while (z)
{
haha += foo (z, z);
z--;
}
return ++x + bar ();
}
What was Richard Stallman on? At least the brace-on-same-line and brace-on-line-by-itself crowds can come together to agree that this is an abomination. Bonus points for spaces between function names and their argument lists, and having expressions with side-effects in an example of good code.
Right Justify¶
Maybe the weirdest style guideline I’ve ever seen was in bluez, a Linux Bluetooth stack.
When wrapping long lines, instead of aligning things reasonably, like
if ((adapter->supported_settings & MGMT_SETTING_SSP) &&
!(adapter->current_settings & MGMT_SETTING_SSP))
void btd_adapter_register_pin_cb(struct btd_adapter *adapter,
btd_adapter_pin_cb_t cb)
the style is to right-align lines after the first, so it takes up exactly 80 columns:
if ((adapter->supported_settings & MGMT_SETTING_SSP) &&
!(adapter->current_settings & MGMT_SETTING_SSP))
void btd_adapter_register_pin_cb(struct btd_adapter *adapter,
btd_adapter_pin_cb_t cb)
These are actual literal examples from their style guide. I have trouble imagining anyone thinking this is easier to read than any of the alternatives.
Good Indentation¶
I’m going to end the list on an example of something rare but good: tabs for indentation, spaces for alignment. Some people write Python code, get burned by mixed tabs and spaces, and ban tab characters (that is an old version; recent versions are more permissive) entirely. Others see that a character for indentation exists, and insist that it should be used.
I tend to agree with the latter camp, but with a caveat:
void function(int arg1,
int arg2, // Spaces for alignment
int arg3,
int arg4)
{
// Tabs for indentation
return bar(arg1, arg2, arg3) + baz(arg4);
}
This lets people with different tab widths still see the code sensibly formatted, Linus’s assertions about the One True Tab Width notwithstanding, while still using tabs for indentation. Besides, alignment isn’t indentation.
Conclusions¶
There’s a lot of WTFery out there in the software industry, and superficial code-formatting styles are usually not worth fighting over. I think the rise of tools like gofmt and its friends in other languages is a great trend that ends a lot of pointless arguments. We’ve adopted clang-format at my company, and while I don’t love it as a tool, life is much better once it’s set up.
Of course, none of that will save you from bad programmers banning
language features like static.