Why I Have Given Up on Coding Standards

I love everything this guy says, too bad its wrong :-)

In the medium case its fine, you'll get folks who write code using a 'common' coding style and for the most part switching between them will be not too difficult. I've observed over the years that a noticeable number of bugs will be introduced by people who didn't read the code correctly.

The place it will go off the rails is when you hire 'that guy' (and it always seems to be a guy) who writes lots of code, and it works, but for reasons that only he understands he only writes it on one line. He likes every function to have its own line, that way he can just use the 'down line' command to get to the next function. And he doesn't really comment anything except sometimes in the middle he'll start a comment between the code that does something and code that doesn't. And someone will have a problem and it will be in this guy's code and they will come to you because they can't read that code and they aren't going to check anything in like that.

At this point a number of entirely predictable things happen. Let's name the players, "Crazy Coder" (CC) who has the bizarre style, "New Guy" (NG) who is asked to fix a bug in CC's code, and "Manager Guy" (MG) the person responsible, ultimately, for all the code.

First there is a blow up when NG takes CC's code, runs it through a pretty printer and reformats it into something they can read, fixes it, and then checks it in. CC has a huge fit that their code has been made "unreadble" by NG and they go back, rewrite all the code that had been reformatted including the NG bug fix, except they won't quite get what NG was fixing and so CC's version of NG's fix won't actually fix the problem. Now NG will be have their bug re-opened because their fix doesn't work.

Now typical escalations are NG assigns the bug to CC since CC won't tolerate his code changes. NG will reformat a big chunk of CC's code just to piss him off. CC will rewrite chunks of the system to invalidate previous fixes by NG and others.

Now as the outlier, MG might want to tell CC to 'change' their coding style to something a bit more standard. They won't. They will insist either there is a coding style or there isn't, if there isn't then there isn't a problem, if there is then everyone has to follow it. And the coding style dilemma will be served up front and center.

Coding style requirements become the lesser of two evils.

The biggest thing to know about coding standards is that many programmers need to stop being giant dicks about it.

By this I mean I've come across people who insist on:

    if (blah) {
      // ...
    }
    else ...

(You're going to be first up against the wall when the revolution comes btw)

Others who insist on 2 space, 4 space or tab indents.

Others who insist on braces on new lines (in Java) or on the same line (in C/C#/C++), both of which go against the prevailing style.

Others who want to static import everything (in Java).

Etc.

None of it actually matters in the absolute sense. The key to working well in an organization is being flexible enough to just do what everyone else does.

At Google we use 2 space indents and 80 character lines (100 for Java). I actually like it now but in past lives I'm more used to 4 space indents and no line length limit. Whatever. It doesn't matter. Get over it (and yourself).

You see this same sense of heightened inflexibility in build systems. Some diehards like Ant (in Javaland) because you can arrange your project anyway you like (with enough XML). These same people chafe against the predefined structures of Maven.

The point of Maven (and organization-wide coding standards) is not that they're empirically the best. It's that they're consistent. You look at any Maven Web app and you'll know where to find things. Seen one, seen em all. Every Ant build is different.

Yet people continue to insist their (non-prevailing) differences actually matter and their exceptions should live on. They don't and they shouldn't.

Code should be written for those that come after you and read it knowing nothing about it. Knowing where to find it and being familiar with the conventions is a huge help.

And don't even get me started on the ASI (automatic semicolon insertion) crowd. That has to be the most idiotic idea in the history of coding styles: forcing people to learn a set of rules about when ASI happens (some of which can be quite subtle) for absolutely zero gain.

Seriously, if any of this gets your back up and you want to protest how ASI is good or how your weird style is important, just stop being a giant d-bag. Your teammates would secretly thank you for it.

As someone who is currently refactoring a giant mess, this is a terrible article.

The problems are myriad:

- we have people mixing camelCase and underscores

- we have tab indents and four space indents, and eight space indents

- program state is all stored in one giant struct, making the code impossible to reuse

- methods are giant, rambling monsters with at least 6 levels of indentation

Coding style is important, is what I'm saying.

This is kind of conflating two different things.

One thing is conventions around things like where curly braces go, naming conventions for classes and methods and different types of variables, how much whitespace to use where, and so forth. Most of these things don't actually matter at all, but code certainly is easier to read if everyone on a team follows the same ones (so that I know that Foo.bar() is a static method while foo.bar() is a method call on a local variable and _foo.bar() is a method call on an instance variable on the class, without having any other deep knowledge of the code). The point of conventions is basically to get everyone to stop bikeshedding about things that don't matter (like which line a curly brace goes on in an if statement), so that they can shut up and go back to writing code. There's no rational way to decide trivial questions like "how much white space should we use," so rather than having people engaging in pointless holy wars over two versus four spaces, we just establish a convention and stop talking about it. It really does make life easier on a team if people are on the same page there, and there are plenty of tools that make it trivial for people to format their code so it conforms to the conventions.

Then there's the issue of "standards," which is a much larger, amorphous topic that probably shouldn't just be trivialized. Trying to encode them formally is probably madness, but when some person on your team writes a 245-line-long function or calls a method "getFoo" when it in fact writes a file to disk as a side effect, you do probably want to have a little chat during a code review to say, "Hey, yeah . . . so that's not really okay, even if the code functions correctly." That's what I think of as "standards:" the assumption that just getting things to work isn't the only thing that matters. And just throwing that out the window and saying "Anything goes so long as it works" is pretty suicidal if you're working on a team.

Coding Standards don't solve every problem and should thereby not be implemented?

The truly evil thing about coding standards is what they do to your heart, your team’s heart. They are a little message that you are not good enough. You cannot quite be trusted. Without adult supervision, you’ll mess up.

No, they simply are conventions making it easier to communicate and understand each others code.

Please go write some code instead. You know who you are.

Yup.

The real answer is "code review by peers."

Should you have a 100-page book of Coding Law that programmers must follow, on pain of firing? No. That's a demoralizing distraction.

Should you say this?

>> You decide if you can sleep at night with random code layouts and inconsistent variable names.

No. That's inviting each developer to leave a mess for the one who comes after them.

How about something moderate and - gasp! - subjective, like, "if your peers find your code confusing, you're doing it wrong?"

>> They are a little message that you are not good enough. You cannot quite be trusted.

I understand the sentiment here, but we're all capable of writing code that's clear to us right now, but isn't to others and/or won't be clear to us in the future. That's one reason why we have code review, and none of us should be ashamed to admit that we benefit from it.

This is absurd.

90% of the time of most devs is spent reading other people's code. Take any meaninful largish project - linux kernel, git, webkit, node. You will spend most of your time reading rather than writing. The least you can do to make this process easier is to conform to a reasonable pattern. Imagine a book that uses a different formatting every other paragraph. It's distracting and gets in the way.

I think the author is more against nitpicking on coding style. This is unfortunately necessary since most developers cannot even bothered to look at the code above and below to understand the style. If that is the case, how does one trust their code?

Coding standards is about basic discipline. If you followed the standard, I know that you are atleast smart enough (and more importantly friendly enough) for a real code review.

On a side note, if you spend most of your time generating new code, you get to set the coding standard. But others who change your stuff, should just follow your standard.

The best thing to avoid a lot of style arguments is to have an automatic code formatter (on save, commit etc.) which takes care of indentations, spaces, braces and so on.

Of course, someone needs to set up the options first, but then, life is so much easier. Sometimes you'll miss the possibility to pad similar assignments to look nicely one after the second, but other than that, autoformatting rocks.

The only really tricky thing regarding autoformatters is styling array literals. For arrays like [1, 2, 3, 4] you want it in one line, but if the elements are longer, you may want to have each of them in a separate line.

Of course, this doesn't handle camelCase vs underscored_variables, but it's a feature to leave you the freedom (or accept some solution in the team).

You know, if there's one thing I hate, it's a set of rigid coding conventions. They're the joy of the petty and officious and the bane of people who just want to get things done. This isn't an excuse to get rid of them altogether. It's an argument for not taking coding conventions so seriously.

I am ordinarily a big fan of articles pushing back against established best practices, but only because despite the sometimes whiny tone, they almost always bring something new and thought-provoking to the conversation.

This article does not.

Loosely related thoughts:

If I feel like it, I can tell my editor to display `underscore_functions` as `underscoreFunctions` without actually modifying the text. I don't feel like it.

Here's my official "coding standards":

Whitespace standards (as in "only spaces" or "only tabs" for indentation) are good. Use whatever's already there. Your VC system can probably handle it for you.

I consider standards for things that don't add ridiculous diff noise as "soft". I'd rather run a tool like sonar that can generate "hey, this is ugly crap" reports with blame annotations than reject commits for style violations. I'd consider rejecting commits for really nasty style violations that weren't covered by tests.

I'd also consider making people wear a monocle if they're going to be doing a bunch of "just style" edits. But meh.

On the other hand, a consistent codebase is a nice thing. If it's a large codebase, a very nice thing ... but it's more of icing on the cake than the cake itself. I don't want to eat a whole bowl of icing.

Python is perhaps rare (unique?) in having a single authoritative, uncontroversial coding standard (pep8). I'm pretty sure its existence solves more problems than it causes.

I think he has a point. Rather than making coding standards where your organization adopts a "best practice", just try to write clean, understandable code. Folks who can mess up, will mess up: we've all seen unreadable "Hungarian Notation" code, we've all seen weird conventions (like all instance variables are prefixed with "my"). They don't help.

There's standards and there's standards.

C allows you to place your braces, commas, other tokens and whitespace in whatever form you desire. I suppose there's no need to get anal over those.

But then there are standards such as assertions, avoiding type casts, and breaking functions into helper functions. Those have an effect on code quality by setting up guards for conditions and sentinels for invariants.

I've had my code blown up an assert call so many times that writing all the rest of the assert calls have cost nothing compared to the savings initiated by forcing myself to evaluate where my thinking went wrong as the assert failed.

Formatting coding standards, again, should probably be banished in favor of letting programmers express their thinking in form of how they format their code. I'm pretty sure the best programmers all have top-notch consistent formatting over all their source code files. And if the worst programmers don't, we have bigger problems than formatting.

I've seen it both ways.

I worked at a company that cranked out 4,000 sites a year. The only way they could do that was by having implicit coding standards. Every bit of code you've written has already been done the same way by ten other developers, 1,000 times over.

It also made maintaining the sites super easy since within a few months you knew 99% of the layouts of every site which was built in the last three years.

On the flip side, for smaller agencies and smaller projects I agree with the author. Trying to impose standards actually hurts the process. Maybe I want to use LESS or some other technology which would vastly improve the code and process, but not make the code super easy to maintain for the next guy. If you only have a few hundred sites, this becomes more manageable.

Besides, do you impose standards on yourself when you're doing projects for yourself or for freelance work?

I'm sorry but no. You can't go wrong with PEP8 for Python and JSHint or something similar for Javascript. Neither of those standards are that rigid and there are tools for most major editors that highlight non-conforming lines as you're coding. Please, put semicolons at the end of your statements.

"Social problems are hard to solve so just ignore them and wing it"?

Not a recipe for success in my experience.

I think I prefer the idea of the style guide, which you might argue is a coding standard, but the use of 'guide' allows for a bit of lenience.

Moreover, I think one of these things is missing the point if it's entirely about syntax, whitespace, and whatever else can make the code appear readable on the surface. There's no substance to this and the code can still be shite while being 100% conformant. It'll just be formatted nice.

What a standard/guide should try to do is serve the dual purpose of educating or informing people about good practices, both in general and while being language specific. Some might disagree or find it patronising, but even if it's only encouraged by colleagues or peers, it can be the sort of thing that makes you think twice about the code you're about to commit.

By the same token, using a style guide for that should never be a replacement for a good, collaborative work environment. This is essentially a people problem after all.

Just plain wrong is all there is to say about this article in my opinion. That said I don't believe that style requirements need to be hyper rigid, they should just prevent people from writing code that is entirely unreadable for no apparent reason.

I can't say I've ever been restricted by a rigid standards document. I do however, attempt to use recommended/best practices for standards in my own code. For the most part I can also say that if others would do the same, it would make me more efficient when maintaining their code.

As far as JavaScript, IMO jsLint is a wise tool to have and use for any project with more than two developers. But by all means, if someone thinks that it's not 'moving the needle', do a double blind study and show us the results. Somebody else, and what they believe worked best in their experience, doesn't really resonate with me unless I'm looking at some hard data that backs it up.

Basically, what he's saying is "I don't enforce coding standards because my programmers are smart enough to choose one by themselves".

Seems to me that what you need more than the standards are the reasons behind the standards - because yeah, the person coding that particular problem knows more than you about that problem, and should /teach you what they know/, particularly when it's easy.

go write some code, don't write blogs.. then.. work with some other guys and theeeennn let's talk about coding standards I would never write such a story about something like "don't use conventions"...

I didn't read the entire article because I am not a novel fan

Standards suffocate me, as any restrictive device should. Even knowing their importance, especially in mission critical roles such as aerospace and medical, it is hard to reason that all the time and creative energy spent on most standards is worth it. Especially since standards evolve by being broken or ignored, creating flux that makes the standard meaningless.

I think the need to form standards are a symptom of poor tools and methodologies for software development.

Robust software needs to be built using first principles. Instead of forming standards in such situations to enforce coding style, we should be improving our tooling, and not be writing code at all. The tools are the standard.

Code is a creative free form medium, and ignoring its raison d'être means killing what it is. If you need precise coloring within the lines, build and use the right tool - a printer. Don't enforce arbitrary rules on using crayons.

clearly, this person has never had to write code within a many-hundred thousand line perl library.

There are certain parts of the spec I dislike, but I thank god everyday I have to look at a new file, because it allows me to focus on what and how the code accomplishes its goal as opposed to minutia like how are arguments passed between functions/methods, what is the naming convention for variables, how are return values returned, or even just do i need to tab indent or space indent in this file?

I use Google's R Code Standard in my code and cut my productivity in half.

I disagree... Because of the tools we have! If only our regular diff tools were able to work on semantic units then we could maybe be laxer on coding standards.

Once again Google got it right in their Go language: there's an official spec as to how formatting should look like and there's a utility, gofmt, which does format the code according to the language's standard way of doing thing and this is a Good Thing [TM].

Coding standards should be directly into language specs and then a "dictator" should mandate compliance with the coding standards before committing (use a hook or whatever suits you) to the (D)VCS.

Now of course you should be able to check out and see, in your editor, the code formatted as you prefer to see it. And it should cause no issues as long you re-format according to coding standards before committing.

This is all pointless ranting anyway: it all comes down to the same age-old issue that we're using text files to represent source code and that these text files can contain structurally incorrect source code.

It's all about the tools. Our tools (editor, (D)VCS, diff tools, etc.) do all really s*ck.

As long as we'll be using such inferior tools to craft our code we'd better have sound coding standards.

I'm pretty sure Google and their Go's gofmt are on to something.

As a side note, OP's rant about chaos that should be reigning king regarding coding standards in a codebase falls pretty flat if you're a Go programming team: the entire Go standard packages have been formatted with gofmt and you'd need something much better than the OP's rant to convince a manager that people shouldn't be using gofmt before committing their code...

Once can only hope language-to-come do not only mandate a very precise coding standard in the language's spec but does actually enforce it (e.g. by refusing to compile a source file that isn't properly formatted).