Slashdot Mirror
Ask Slashdot: Do Coding Standards Make a Difference?
An anonymous reader writes "Every shop I've ever worked in has had a 'Coding Style' document that dictates things like camelCase vs underscored_names, placement of curly braces, tabs vs spaces, etc. As a result, I've lost hundreds of hours in code reviews because some pedant was more interested in picking nits over whitespace than actually reviewing my algorithms. Are there any documents or studies that show a net productivity gain for having these sorts of standards? If not, why do we have them? We live in the future, why don't our tools enforce these standards automagically?"
We have always had standardized checkstyle and jtidy rules as part of our build system. We have eclipse formatting configuration that everyone uses as well. Commits don't happen unless checkstyle is happy.
I thought everyone did this. I guess tooling is less developed in some languages, but it's not too hard to put this kind of thing into practice with a little bit of effort and buy-in.
Once I was put on a project with rather strict standards. I didn't like their naming conventions, and the style was noticeably different from mine. But I soon found that whichever of their programs I was assigned to, it was relatively easy to follow because of the similarity with the other programs in that system. In contrast, the system I'd been on before had no standards, and everyone did things their own way (including me), and I had to study each new program before making any significant changes.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
I disagree. things where to put the braces (on a line alone vs end of statement), tab size, Camel vs. underscore.... to me those are all personal preferences.
A couple of trivial examples of why this makes reading code much easier:
The coding standard says "open braces should always appear on the following line, all control flow statements should have an associated brace." This code is now not allowed:
if (some(really) && long(condition) || that(extends) && miles(across(the, line)) || and(pushes, the, code, to(the), right, off, the, screen)) doShit();
doSomeStuff();
Instead, this is needed (though some extra coding standard rules would be useful to clean it up further:
if (some(really) && long(condition) || that(extends) && miles(across(the, line)) || and(pushes, the, code, to(the), right, off, the, screen))
{
doShit();
}
doSomeStuff();
Now, I can scan read this code, and see that doSomeStuff() is always executed. I don't need to read the whole line just to check if some one's left something on the end of the if statement.
Another trivial example, a coding standard might say "expressions should only contain pure values, never state changes. If you need to change state, use a statement." Now this code isn't allowed:
someFunctionCall(blah(boo), foo, baz, bar, monkies, brains, xyz++, [self setCheese:29], unsafeLaunchMissiles());
I now as a reader, no longer need to scan all the arguments to find out if there's a state change in there. This makes code way easier to understand.
So yes, simple, apparently "trivial" coding rules can make an enormous difference to the readability and maintainability of code.
why don't our tools enforce these standards automagically?
They do. Almost every modern IDE will format to a standard and mark code that is not to that standard. Tools like "checkstyle" can document code that is not correct during the develop or build phase. That is why no one is wasting anyone's time here having a corporate standard. Comments about how many hours where lost "picking nits over whitespace" tell the story of developers who are too uninformed, ignorant or more likely self important to follow simple guidelines that for the most part can be automated. These are exactly the type of developer I want no where near my code base. If they won't follow the style standard they sure a f&*$ won't use the DAL as intended or follow the MVC standards. They are the developers who spend 1000 hours generating their own XML parser because they don't like they way DOM or SAX work. Having a standard does not waste time, but the kind of developer who won't follow it does.
No sigs in BETA. Beta SUCKS.
Not sure if you are being serious with your point or not due to your case changes, but I will bite.
Just because a style is standardized doesn't mean your code is more readable using that style. In fact a lot of the styles expected of me made my code less clear, and when I chose to ignore them, my code was never touched in code reviews, because everything was clear and intuitive without conforming directly to the style.
If you personally like clear / readable code, then no standard will ever be a replacement for you.
You're missing the point. I am not claiming a particular coding style is superior, I am claiming a standard coding style across the whole code base is good - personal preferences aside.
PS: I'm talking about basic stuff here, such as having standards on how to name variables, constants, camel case?, self documenting code?, etc.
diegoT
Brace position and spacing both are encompassed by the whitespace argument that I was referring to.
Except that a diff isn't going to ignore whitespace when broken across multiple lines, verses a one liner. See also: Python.
You're preaching to the choir, btw, but also you're making the wrong argument. Whitespace does matter, it just shouldn't matter how it's configured, just that it's consistently applied.
The reality of the situation is that if I reformat a 100 char line to be broken across lines with max 80 chars, and go back and forth doing this it thrashes the code repository. Diffs are general purpose, they don't understand code syntax, you've used them haven't you? Newlines are whitespace. They don't lexically parse code ignoring all whitespace, they work line by line. However, Compilers DO understand their own syntax! IMO, all compilers should have the option to lex & reformat inputs to whatever style you want based on an input rule sheet of some kind. Currently this is handled disparately in a non standardized way by IDEs, scripts, etc. In fact, many projects will have a script or program that you should run your code through before committing it. This allows you to code however you like, while giving the codebase a consistent and uniform look.
Any moron complaining about whitespace in code doesn't really belong in coding.
I find this statement moronic and/or ignorant. If you don't think that a uniformity and consistency help while reading and understanding text (including code), then you've never studied the human brain much at all. We're pattern matching machines. If the patterns change from page to page then it IS actually harder to read. The first thing I usually do when working on a new project is equip my editor/IDE with a style guide for the project to transform all code into my preferred style while editing. Then I can edit in the pattern than I'm most used to dealing with -- It's faster because that's how brains work. Being more efficient and taking advantage of my brain's natural tendencies isn't moronic, it's smart.
On save, or before commit the code is transformed into the project's style guide by an auto formatter. I think this is the best, because I have cognitive science research to back it up, repetition of tasks builds "muscle memory", etc. So, my use of whitespace rules is actually faster than adapting to each project. Now, given that we don't have all compilers with such option to transform data on the fly to our preferences, and we can't always rely on the other coders to be using IDEs that can do this, the next best thing is having a project wide coding standard, and that's exactly what we do. Seriously, what sort of experience do you have where you haven't run into this commonality yourself? What's more likely that everyone is wrong but you or that we've all been down the road before and have arrived at a common consensus? Level up your knowledge. To me you sound rather ignorant and quick to make assumptions, thus foolish.
Disagree. There are different naming conventions for things like constants and class members. The point of these conventions is to make it clear from the name of the variable what the variable represents. If you aren't confident that the code base is consistently following the same conventions, you have no confidence that something that appears to be a local variable is actually a local variable, which means you need to spend more time poking through code in order to understand it.
Consistency begets readability, and readability begets maintainability.