
Why I Have Given Up on Coding Standards - redDragon
http://www.richardrodger.com/2012/11/03/why-i-have-given-up-on-coding-standards/#.UK0lZ4ZcEeN
======
smoyer
The goal of a coding standard isn't conformity ... it's correctness and
maintainability. The first step is to hire people who care that the code they
write is correct and maintainable. The second step is to write unit tests that
cover the non-trivial portions of the code-base. The third step is to conduct
peer code reviews - everyone can learn something and this especially helps
junior programmers. The fourth step is to use tools to help you know which
parts of the code base need attention.

My favorite tools (FindBugs, CheckStyle, PMD, JSlint, CppCheck, valgrind,
vera++) can all be incorporated into a system I consider invaluable - Sonar
(<http://www.sonarsource.org/>). If you add the SIG MM plugin (Software
Improvement Group - Maintainability Model), you should have the tools you need
to know how good your code really is.

Of course, whether you strictly follow every recommendation or not is up to
you (there are false positives), but at least you have a basis for deciding
what your "coding guidelines" should be.

~~~
robmcm
It's not conformity or correctness it's maintainability though consistency...

I would much rather work under a standard that was the total opposite of what
I am used to, that have none at all...

~~~
smoyer
When I said "correctness", I meant that the software performed its intended
function, not that the software correctly met a standard. Sorry for the
confusion (I'm assuming you don't disagree with wanting software that's
correct for this definition).

------
macalicious
Third duplicate. <http://news.ycombinator.com/item?id=4815647>

------
jacques_chester
In which the author fights actual evidence with ... a fictional anecdote.

~~~
tterrace
He really could have done without that bizarre strawman narrative in the
middle and provided an actual argument besides "You're all wrong, just stop".

------
chris_wot
So this is a blog pushing a POV about the evils of pushing your POV on coding
on others, all based on the authors life experiences which he admits are
problematic.

------
rumcajz
Coding standards are here to prevent developers to waste time by bikeshedding
about irrelevant details of the style. From that point of view, if "no coding
standards" rule eliminates silly coding style controversies, it is a perfectly
acceptable coding standard itself.

~~~
Evbn
But then it turns files in too a gibberish mess of fixed styles, or constant
churn cluttering the VCS history as people reformat each file they touch.

------
Zenst
A article about standards hosted in a format that is standard else we would
not be able to read it. Beyond that nothing too see here.

Next week I expect a blog of 20 pages explaining why you don't document code
as it takes too much time typing.

Of course I totaly disagree with the author, but I highly suspect that in a
few years time he himself will also agree to disagree.

Standards are whilst not perfect a level of commonality that binds the code so
that others can see and use the code, oh and adds other perks like reduces
bugs, makes things just easier for others to work on others code. But anybody
who just codes by themself not touching others code will equaly have a
mentality that standards are wrong. See the problem.

------
jheriko
did anyone else read this as '... because I am shit at my job'?

I'd accept an argument against poor, or draconian standards, but actually
standards can stop people from doing dumbass stuff or hitting subtle gotchas -
esp. useful for junior developers who might not understand the intricacies of
static initialisation order or memory alignment in C struct layout...

~~~
nicholassmith
I more read it as "stop wasting time arguing over tiny details and code",
rather than "I'm bad at coding and don't like being told what to do".

Things like the two you mentioned are useful as a code standard, but they're
also things that junior devs should be learning from senior devs in the
process of work anyway. There's no point slavishly following a standard if
you're going to never learn from it.

~~~
chris_wot
Yeah there is. Preventing bugs due to coder inexperience is valuable in its
own right.

~~~
brokenparser
No, coding standards bicker about such frivolous things as whether to use _,
m, or m_ for member variables. Just pick one and stick with it. Arguing over
one or the other is both useless and utterly stupid.

~~~
chollida1
> Just pick one and stick with it.

Well, by definition, you've just created a coding standard.

We often just start out using the standard of someone who has thought it
through.

Crockford for JS, Microsoft for C# and Google for Java.

If someone raises a complaint, we do consider it but then the onus is on the
developer to justify why it should be changed and that means the developer has
to have thought out his/her idea, which is what you really want to begin with.

If it's something as trivial as marking members with "_" or "m_" then it will
be a non starter due to,as you said, it just doesn't matter as long as your
consistent.

------
pgambling
This point really stuck with me:

"Fourth, good intentions; best practices; professionalism; engineering – the
seductions of process. You are chasing the same gold stars you got when you
were eight years old. But how is the master craftsman judged? By results,
only."

It's true that we love to talk coding standards and development processes
because it feels productive. At the end of the day, delivering a working
product is true productivity.

~~~
bbotond
Delivering a working product that will continue working for years, and is easy
to understand, fix and extend, is true productivity.

~~~
robmcm
Correct, delivery is ongoing not just version 1.

------
blackhole
I want to state my opinion about this, but as most of the comments
demonstrate, nobody in this debate is really listening to the other side.
Instead, we simply have people trying to yell out their opposition as loud as
possible in a long string of "You don't understand!" "No, _you_ don't
understand!" ad nauseum.

Throw in thousands of Correlation does not imply Causation logical fallacies
on both sides, and you have one of the most dysfunctional and useless
arguments in all of programming literature.

------
RTigger
I ended up writing a blog post in response to this:
[http://rtigger.com/blog/2012/11/22/design-standards-vs-
code-...](http://rtigger.com/blog/2012/11/22/design-standards-vs-code-
standards/)

Synopsis: I like Michael Feathers’ comment that having Design Standards is
much more valuable than Code Standards, but they need to be reviewed regularly
in order to prevent stagnation and much of the same detriments mentioned in
the OP.

------
bobinator30
at my startup, we didn't have any coding standards, except one: don't reformat
other people's code.

this meant that the original author of the compilation unit (uh, file) had the
freedom to do what he wanted, and other people who made modifications had to
conform to the original format.

the results:

1\. no fights over coding standards, although we did have plenty of banter

2\. it taught people to respect the other people's style if they wanted their
own style respected, thereby making everyone complicit and fluent in every
style

