
Why I Have Given Up on Coding Standards - hodgesmr
http://www.richardrodger.com/2012/11/03/why-i-have-given-up-on-coding-standards/#.UK0hmuOe89E
======
ChuckMcM
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.

~~~
polarcuke
This is exactly what I was thinking as I read the article. There really are
"Crazy Coder's" out there who write obfuscated code just because they can and
it's infuriating.

~~~
cfn
Well, the problem then is the guy and forcing rules on the whole team instead
of solving the root issue sends the wrong message all around.

~~~
gte910h
Exactly! Policy is rarely the correct answer when firing and reprimanding the
troublemaker work too!

------
cletus
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.

~~~
sixcorners
In C, braces on a new line is the prevailing style? I've been doing the
opposite because that's what K&R C does (except for braces that define
functions).

------
alanctgardner2
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.

~~~
barrkel
What you are complaining about is incompetence, not a standards document.

~~~
alanctgardner2
I wouldn't describe it as incompetent, it's just not forward thinking. We have
a loosely enforced style guide that should prevent the formatting and casing
issues, but what we need is actually a more dictatorial approach.

As I'm rewriting, I'm producing a style guide which is more prescriptive about
things that matter, like writing reusable code. This includes trying to
identify hotspots where extensibility is very important, versus areas where
the code just needs to be readable and work. These deserve more love and
attention from an architecture perspective.

------
akeefer
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.

~~~
nradov
The way I addressed your "standards" issue is to just reference the book "Code
Complete (2nd edition)" <http://www.cc2e.com/> and tell developers to follow
all of those guidelines. It's a long book but well worth reading, and
generally applicable to most any procedural or OO language.

For Java specifically our "standards" also incorporate the book "Effective
Java (2nd edition)" <http://www.informit.com/store/effective-
java-9780321356680> .

------
VMG
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.

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

A 1 page coding standard picking which common conventions people use perhaps
is making it easier to communicate, maybe.

A 10 page coding standard with lots of positive manual actions a coder must do
at ever step that don't necessarily add to the process (I'm looking at
contracts in private functions and hungarian especially), or that are outdated
and not state of the art, is positively soul-killing to many people.

Most places need code reviews, not coding standards.

------
nathan_long
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.

~~~
gte910h
Thank you. If your coding standard appeals to the aspergerish folks more than
the neurotypical, it's probably going to sap the energy of the nerotypical and
drain productivity out of the process.

------
general_failure
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.

~~~
gte910h
>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.

Some coding standards are basic discipline. Others are overwrought bullshit
that are a drain on concentration, spin up time with new employees, and a
constant sap on productivity in order to make stuff a slight bit prettier.

------
jakub_g
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).

~~~
gte910h
Do you know of one that works for Objective-C?

------
j_baker
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.

------
jrajav
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.

------
kaens
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.

------
Joeboy
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.

~~~
usea
Go ships with a tool called gofmt which automatically formats your code to a
particular convention. It's expected that you gofmt all code that is released
publicly. It also solves more problems than it creates, even if I don't agree
with all of its rules.

~~~
chimeracoder
Go is much, _much_ more strict than Python. Python is actually fairly
forgiving when it comes to whitespace everywhere _except_ for indentation. And
for indentation, it doesn't complain as long as you're consistent (for both
tabs vs. spaces, and if you choose spaces, consistent with the number of
spaces).

Go, on the other hand, checks for many aspects of style at compile-time. If
you include an opening brace on the same line, import a package that isn't
used, define a variable that isn't needed... all of those will cause compile-
time errors.

At first, it can get annoying - especially when you comment out a single line
when debugging and then realize you have to make some other minor change
elsewhere just to avoid one of the aforementioned style issues.

But on the other hand, I can't deny that it makes my own code cleaner, and it
probably saves some errors down the line. Furthermore, it made my code more
consistent with existing Go code right from Day 1, even when I was just
learning the language. Furthermore, for anybody who wants to do any
metaprogramming/code translation, having a more rigid syntax enforced by the
compiler is very helpful.

Python doesn't do that. PEP8 is great, and I'm thankful that it's very widely
followed. But it's much more powerful when these issues of "style" are made as
mandatory as any other aspect of the language specification[1].

This "benevolent dictator" approach has its pluses and minuses, but having
written Go code a short while now, I've come to appreciate some of its
benefits in the case of coding style.

[1] Okay, so the Go language specification doesn't include all of these, and
yes, there are two independent Go compilers. But we can say that it's
"mandatory" in the same way that we can say that "Python" has the GIL, when in
reality many implementations don't (Jython, Iron Python, etc.)

------
bediger4000
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.

~~~
gizmo686
so, is it foo.getSize() or foo.GetSize(). Naming all instance variables my*
might or might not be very useful, but naming some instance variables that way
is defiantly harmful. The point of having standards and conventions is that
you can just know what arbitrary and useless decision others have made,
because it is not arbitrary, it is the standard.

------
yason
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.

------
at-fates-hands
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?

------
cdelsolar
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.

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

Not a recipe for success in my experience.

------
FuzzyDunlop
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.

------
polarcuke
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.

------
rizzom5000
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.

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

------
nickbarone
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.

~~~
Negitivefrags
That doesn't work at all when it's religion.

Using spaces for indentation is a sin against humanity, but that doesn't mean
that someone else isn't going to come along and believe otherwise and no
argument you make will sway them.

~~~
nickbarone
Well, but then your problem is religion, not coding standards. And then it'll
be over this or that design pattern, coding paradigm, version control commit
logs....

If you name the problem "coding standards" and it's "religion", you'll solve
the wrong problem and of course it won't work.

------
mal3x4u
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

------
pirateking
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.

~~~
alanctgardner2
This is ridiculous; there's certainly a place for creative code. It's an
obfuscated code competition. Yes, you can write a BrainFuck interpreter in the
C preprocessor. If it was your job, would you do it that way? Would you saddle
other people with the work of maintaining your implementation?

The second half of your argument is equally vexing. Yes, ideally tools would
turn intent into actions. We would think, or express what we want at some high
level, and it would come into existence. That's not how the real world works.
Painters need to use a brush, musicians need an instrument, or at least sheet
music.

Some would argue that brushwork is like coding style. But the thing is, do you
want to work on a team of Jackson Pollocks?

------
joshAg
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?

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

------
martinced
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).

~~~
gte910h
I think if specifed at the language level (pep8/python, gofmt/go,
objectiveC/apple docs), that's one thing. Additionally, if you have complete
tool support for your format, you can demand much much more from the
programmer.

The issue is making a guy constantly REMEMBER, Keep in mind, and implement
something NOT enforced by a compiler is a huge sap on a certain type of
person.

