Ask Slashdot: Do Coding Standards Make a Difference? 430
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?"
After 42 yrs programming I say... (Score:5, Insightful)
...yes but not very much a all. Nothing beats clear thinking.
"a net productivity gain"..YES (Score:5, Insightful)
Yes, they do (Score:5, Insightful)
I find it impossible to believe that anyone has actually lost hundreds of hours in reviews due to style, unless they were purposely not following what are usually pretty simple guidelines.
The differences between one style and another are meaningless, but the value of having a consistent style across an entire codebase is, in my experience, enormous. If everyone can read your code as though it was their own, that does in fact save hundreds of hours of time across the team.
Don't forget the Terms and Acronyms (Score:5, Insightful)
Listing the meaning of every acronym, no matter how well known, that's my favorite part of document reviews.
Coding standards save the hundreds of hours of somebody else going through your code and re-indenting it all so that you can't diff it any more.
It's your responsibility. (Score:5, Insightful)
We live in the future, why don't our tools enforce these standards automagically?
Some do. As the developer it's your job to make sure it happens, however you do it.
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
Was the nit picker correct? That is, was he pointing out true variances from the standard? If so, the fastest way to appease him is to cram your ego and make the changes. If you're arguing about something that is clearly spelled out in the coding standard, then YOU are the one who is wasting time by arguing about it. If not, and the nit picker is just slinging shit, then call him out for wasting time in meetings.
Naming, sure. Whitespace? No. (Score:5, Insightful)
But nit-picking over whitespace is simply annoying. Any person who insists on that much compliance might be trying to compensate for lack of performance in more important areas.
It's about conformity, not code (Score:2, Insightful)
It's a test on following orders and attention to detail. We don't need any of you rogue coders 'round here, see?
Write a pretty print! (Score:4, Insightful)
With such poor standards as white space and curly braces, write a pretty routine to clean it up. One to convert to your standard and one to convert back to theirs.
I come for the world of 6 upper charter names names for fields/columns. There naming conventions mean something becuase every is abbrivated. We keep or stnadards on single sheet of paper to so that could be followed.
Now get of my lawn!
Re:"a net productivity gain"..YES (Score:4, Insightful)
I have inherited metric craptons of code. Variable declarations and naming conventions were NEVER the problem I had. It was spaghetti code. It was unfactored code. It was a mismatch between code and requirements. It was a lack of requirements documentation. It was duct tape fixes in code rather than understanding the problem.
While I like well defined variables, I can live with vaiable names of 'i' or 'j' or 'MyString' even it defines a float.
-MyLongNickName
Ya to me sounds like "I'm special" syndrome (Score:5, Insightful)
This guy thinks he's the shit programming wise and thus has to do his own thing. He's too good to be bound by the rules of everyone else. So he keeps fucking up and then crying about it.
His company should just can him.
Re:Naming, sure. Whitespace? No. (Score:2, Insightful)
You are wrong. Everyone on the team is using spaces, then OP starts using tabs. The tabs look fine in his IDE so he doesn't care, then someone tries to use vim for a quickly check/change something and indentation is screwed up everywhere OP made an edit.
Re:After 42 yrs programming I say... (Score:5, Insightful)
Can't agree with "not very much at all".
I don't really care what coding standard you use, pick one any one. But here's the rub, pick one and stick with it.
I get really exhausted and tired having to jump between 4 or 5 completely different coding styles in the same project. And I'm not just talking about indentation and formatting. I'm talking about how problems are solved.
For example: If you're coding in Java and the "style" is to Using Apache StringUtils for what it does, then use that. Don't go create your own monster mess that does the same thing, then force me to take 15 minutes to figure out you re-wrote StringUtils for no damn good reason.
I've watched developers struggle with this and waste hours upon hours tracking down bugs because of stuff like this. And, you know what? They never want to admit it's because the code is a typographical mess that puts your eyes into unending calisthenics.
Re:After 42 yrs programming I say... (Score:4, Insightful)
Personally if you have a coder using myVar and my_var for two different variables in the same code, I think you have more to worry about that coding style.
Re:"a net productivity gain"..YES (Score:5, Insightful)
Coding standards decide whether you should do "goto SomeLabel" or "goto someLabel"; they don't prohibit crap code.
No standard can prohibit crap code because there will always be situations where the standard is the cause of crap code (i.e.; there are cases where using "goto" make for better code).
Re:After 42 yrs programming I say... (Score:5, Insightful)
Most diffs can ignore whitespace...
I don't understand your second point.
You didn't understand his first point.
Re:Long story short... (Score:4, Insightful)
If you're whining about the details of coding standards, if probably means you aren't good enough to whine about something important.
I've used numerous different coding standards for numerous different languages; every project and every team seems to have it's own standard. Just learn their preferences, use them and get code done. Very few coding standards are bad enough to care about. Usually a project has far more important issues to address than whether you should use PascalCase or camelCase.
Re:Ya to me sounds like "I'm special" syndrome (Score:5, Insightful)
Wanting to be exempt from standards because you're "special" is a sign of immaturity. He may not need to be canned. He just needs to grow up or go lone-wolf-coder where he can live in his own special world.
There was a post on /. (12/19) that answered this. (Score:5, Insightful)
"How Experienced and Novice Programmers See Code [slashdot.org]
From one of the links:
-Eric Holk
Re:After 42 yrs programming I say... (Score:5, Insightful)
Assigning blame to people because of bugs is in fact one of the most detestable things you can do in software development. Bugs will always exist, no matter what coding style you use. If your first priority is to name and shame and not fix the code and move onto the next issue, then your teammates are going to hate you.
Re:After 42 yrs programming I say... (Score:5, Insightful)
Re:Yes, they do (Score:5, Insightful)
The differences between one style and another are meaningless, but the value of having a consistent style across an entire codebase is, in my experience, enormous. If everyone can read your code as though it was their own, that does in fact save hundreds of hours of time across the team.
This statement reminds me of the player who having alway played red or blue team are soo fixed in thinking they become incapable of switching sides without constantly trying to kill their own teammates while everyone else has the capability to do so in a moments notice with no mental effort.
It must be nice to only have to deal with code from yourself or your organization. We don't have that luxury. We have to work with code from external sources that will ignore us if we try and dictate style.
In my opinion the superficial style elements mentioned in the summary only help the pedantic control freak types. You are ultimatly better off promoting a more permissive environment where the small pedantic shit is not sweated. Let everyones minds adapt to dealing with diversity and there will be no mental cost. It also makes both employee churn and reality of external code much easier to deal with in the long run. I find it also helps give an idea of who may have done what at a glance without having to sort through the RCS.
Having conventions is still a good thing.
Re:After 42 yrs programming I say... (Score:5, Insightful)
Exactly!
After you use a few different coding standards an experienced developer doesn't care _what_ the actual standards (such as http://en.wikipedia.org/wiki/Indent_style [wikipedia.org] ) , just as long as EVERYONE follows them.
Re:Long story short... (Score:5, Insightful)
I think designing and writing code is a form of art, and you wouldn't tell a painter how to to draw his strokes, or a writer to always write sentences in a well defined style.
Hahahahaha. When companies pay writers or artists to work on a shared piece they sure as hell mandate all those things.
Do you think all the artwork in a game has consistent style by some black magic? Hell no, all the artists are told what style to adhere to and they do. Same with writing. Same when artists collaborate. Would you want to read a book that randomly switched fonts and writing styles every few paragraphs?
If you want to do your own thing then fine but don't expect to do so on someone else's dime. They're paying you to work as part of a team, stop being a whinny immature child.
Re:After 42 yrs programming I say... (Score:4, Insightful)
Re:After 42 yrs programming I say... (Score:4, Insightful)
And you're missing my point when I say that just because a particular style is standardized doesn't mean it produces self-documenting code. If the person in charge of setting the standard is an incompetent programmer to begin with, then his standard could introduce confusion. There are many examples of this happening on the daily wtf. And in fact, I have had managers that have tried to enforce standards which would turn my code from easily understandable to a mess of variable acronyms.
To a competent programmer, stardards are more of a guideline. Any good coder knows how to produce clear and maintainable code, and should be able to read similarly clear code even if the case of the variables are different or there is an endline after the curly braces. Bad coders need and cling to these rules, however, because without them they would literally have no idea what to do.
Re:After 42 yrs programming I say... (Score:5, Insightful)
And you're missing my point when I say that just because a particular style is standardized doesn't mean it produces self-documenting code.
But that's not what you were arguing first. You were arguing that diffs can handle differences in whitespaces (and obviously, indentation is more than just that.) Maybe I'm missing the point you are trying to make. Standarization is not a necessary condition for self-documenting code, but that's not what they are for. Styles are for having a normalized structure with which to collaborate. Self-documenting code is a related, but different issue altogether.
Re:After 42 yrs programming I say... (Score:5, Insightful)
Is it better to drive on the left side of the road, or the right side of the road? There might be some argument to be made that one is better due to most peopl ebegin right-handed, but it's not going to make much of a difference.
But it's really important that everyone drives on the same side of the road.
It's simply faster and easier to read code that has style standards followed throughout. Even when they're pretty stupid.
Re:After 42 yrs programming I say... (Score:2, Insightful)
Exactly!
After you use a few different coding standards an experienced developer doesn't care _what_ the actual standards (such as http://en.wikipedia.org/wiki/Indent_style [wikipedia.org] ) , just as long as EVERYONE follows them.
A big plus one to that.
This is what annoys me about the original question -- the OP is getting upset over someone else dictating how he formats code, and calling them a pedant for fixing it, without seeing his own hypocracy, where he's too inflexible to accept the standards that are already in place.
Re:Standards are (_Not_ Usually) Good (nor bad) (Score:4, Insightful)
Standards and enforcement of same is (usually) a symptomp of the "interchangeable morons" school of management. It presumes that all problems have a (ayn rand-ish) uniform solution that all _programmers_ will process identically.
A small number of "do not do"s with a "unless you have good cause" _guidelines_ are reasonable, but something as firm as a "standard" is a great way to make your great programmers no better than your worst over time.
Standards often contain bugs themselves. Things that create a hidden cost on the programmer and the program that can bog both down.
examples:
Even Microsofte eventually abandoned their "Standard" for putting the variable type as encoded dirt on the front of their varialbe names such as "lpintThingy" having plagued their code with Thingies that are no longer long pointers to integers and that cannot be globally searched and replaced because that hazards destroying other code.
Combined rule failure (use getters and setters + don't put member function definitions inside of class definitions => what would be a register load operation becomes an optimization resistant far call across translation units ** every dang time you set or read a scalar).
If you cannot trust your programmers to write good code then making them format it so it _looks_ like good code is a wasted effort.
If you cannot trust your great programmers to write great code eventually they will stop even trying to do so and you will be left with a hassle avoiding idiot or someone looking for a new job.
If you cannot trust your new programmers to understand your previous code then your new programmers are probably inferrior to your older coders.
If you are not winnowing out the _bad_ programmers via rational code review then your management is useless.
All but the most rudimentary coding guidelines are productivity and creativity and performance murderers.
Every company eventually realizes this, on and off, for a while, each time a management team ages into a job, and then forgets it again when they hire new managers.