Why I Have Given Up on Coding Standards | Hacker News Reader

Why I Have Given Up on Coding Standards

richardrodger.com

29 pointsredDragon25 comments

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.

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

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

Third duplicate. http://news.ycombinator.com/item?id=4815647

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

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

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.

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.

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.

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.

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

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.

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

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.

If you have a standard then you've already picked one, there isn't any argument at that point.

Picking one and sticking with it is what a coding standard is.

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

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.

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.

I agree that delivering is everything that matters... when you work alone and you won't ever have to maintain your code after release.

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

Correct, delivery is ongoing not just version 1.

Interestingly Master craftsman operate to a detailed contract where the patron specifies virtually everything of interest. It's very far from a results only mindset. All those people we thought of as great artists before Michelangelo were considered craftsman in their day, someone with a skill employed for money, like a baker. As a programmer on a team you are operating on behalf of a patron and it's their rules over an artistic/star/look at me temperament. To argue for a design standard and not a coding standard is like saying an architect shouldn't care how their bricks are made when it's really the quality of the bricks that dictates structure under stress. If you are building something that isn't under stress you don't need an architect, you don't need to worry about structure, you can just let your heart move you. But when you are building something that matters, that someone is paying for, that is subject to extreme stress, then structure dictates both form and function and a key part of structure is code, so that's why you have a standard. Unfortunately with code we are still stuck in a highly empirical age, so the standards are experience based and highly arguable, so there's a lot of room for displeasure. But Gothic cathedrals were built to the sky using lessons learned from experience and that's essentially what we are doing with software systems.

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.

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

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.

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

Reply on news.ycombinator.com