Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Do Coding Standards Make a Difference?

Soulskill posted about 2 years ago | from the everybody-do-it-wrong-the-right-way dept.

Programming 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?"

Sorry! There are no comments related to the filter you selected.

After 42 yrs programming I say... (5, Insightful)

rs79 (71822) | about 2 years ago | (#42362725)

...yes but not very much a all. Nothing beats clear thinking.

Re:After 42 yrs programming I say... (5, Interesting)

man_of_mr_e (217855) | about 2 years ago | (#42363027)

Coding standards were largely developed to prevent developers from reformatting each others code in a format war.

Joe works on code, checks it in. Bill gets a task to work on that code, doesn't like Joe's formatting, so he reformats, checks that in.. Joe works on the code again, finds it's been reformatted, then he reformats it again.

This is hell when doing diff's and figuring out what changes from version to version. Coding standards help to prevent that.

Another reason for coding standards is to set a level playing field for everyone.

Re:After 42 yrs programming I say... (1, Informative)

casings (257363) | about 2 years ago | (#42363055)

Most diffs can ignore whitespace...

I don't understand your second point.

Re:After 42 yrs programming I say... (5, Interesting)

Decameron81 (628548) | about 2 years ago | (#42363115)

THE reaSON WHy coDiNg standards_exist is thatTheyIncrease THE_REaDABILITY oF YOur cODe.

Re:After 42 yrs programming I say... (1)

XxtraLarGe (551297) | about 2 years ago | (#42363129)

Most diffs can ignore whitespace...

Yeah, but they don't understand that myVar and my_var are actually supposed to be the same variable...

Re:After 42 yrs programming I say... (3, Insightful)

casings (257363) | about 2 years ago | (#42363147)

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:After 42 yrs programming I say... (5, Insightful)

BasilBrush (643681) | about 2 years ago | (#42363169)

Most diffs can ignore whitespace...
I don't understand your second point.

You didn't understand his first point.

Re:After 42 yrs programming I say... (5, Insightful)

gantzm (212617) | about 2 years ago | (#42363091)

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

DickBreath (207180) | about 2 years ago | (#42363107)

Coding standards make code easier to read. In many shops they are probably unnecessary. But there are outliers where code is completely unreadable. I remember in the 1980's seeing a guy's Pascal code that was formatted as if it were assembler. (Yes, I'm serious.) That is why coding standards are needed, why they CAN make a productivity difference, but in most cases, not much.

It's too bad we can't have clear thinking standards.

"a net productivity gain"..YES (5, Insightful)

who_stole_my_kidneys (1956012) | about 2 years ago | (#42362733)

because when you leave\get fired\DIE, everyone can read your code and not have to interpret it, thus productivity gained.

Re:"a net productivity gain"..YES (-1)

Anonymous Coward | about 2 years ago | (#42362947)

[citation needed]

Re:"a net productivity gain"..YES (4, Insightful)

Anonymous Coward | about 2 years ago | (#42363009)

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.


Re:"a net productivity gain"..YES (1)

davidwr (791652) | about 2 years ago | (#42363039)

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.

Either your company's coding standards didn't prohibit crap code, or previous employees didn't adhere to the standard.

Re:"a net productivity gain"..YES (4, Insightful)

mwvdlee (775178) | about 2 years ago | (#42363151)

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:"a net productivity gain"..YES (0)

Anonymous Coward | about 2 years ago | (#42363159)

You mean people actually *PAY* programmers who are so shit at code comprehension that they can't work on code not in their indoctrinated style?!

Fucking do me a favour.

Reading and writing code in styles even vastly different to mine has no measurable impact on my productivity. However, a problem clearly stated and directly, concisely solved is absolutely always going to result in better productivity than the sort of shit I see being written by the sort of programmer who thinks coding style bears anything more than an aesthetic quality.

Re:"a net productivity gain"..YES (1)

LSD-OBS (183415) | about 2 years ago | (#42363193)

(I left out the only 2 things I care about in coding style: consistency and structure. The former speaks for itself. The latter is stuff like avoiding stupidly deep indentations due to poor block / control structure)

Standards are (Usually) Good (2)

craigminah (1885846) | about 2 years ago | (#42362737)

I doubt there's any productivity gain by the people who write in a particular style but I think corporations want things done a specific way so other people can work on code someone else developed. When standards get too restrictive they can create problems. A few decades ago when I moved from Pascal to C I wrote a program to reformat my code into a standardized format...wasn't too difficult and it allowed me to focus on the algorithms, content, and GUI rather than the style of the code itself. Seems like it'd be a good thing for corporations to have...a tool that auto reformats into a standard corporation-approved format.

Re:Standards are (Usually) Good (2)

Shimbo (100005) | about 2 years ago | (#42362919)

I doubt there's any productivity gain by the people who write in a particular style but I think corporations want things done a specific way so other people can work on code someone else developed.

Agreed, code is write once read many; it's a bad sign if a developer thinks their time is more important than everyone else's. Spending time in code reviews on it is clearly wasted though, when it ought to be automated. Someone will no doubt point out that Alt/beetroot soup/testicle in Emacs does the job.

Re:Standards are (Usually) Good (1)

jellomizer (103300) | about 2 years ago | (#42363013)

Also they should be strict on abiding by these standards if they are not, then slowly formatting will follow the slope down to an unreadable level.

I have seen code from companies without coding standards. You can tell the age of the code just by how it is formatted.
Often with new code out of spacing or just everyones particular style everywhere with different degree of variable names it just makes it harder to read.

Yes, they do (5, Insightful)

Anonymous Coward | about 2 years ago | (#42362749)

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.

Ya to me sounds like "I'm special" syndrome (5, Insightful)

Sycraft-fu (314770) | about 2 years ago | (#42363023)

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.

Don't forget the Terms and Acronyms (4, Insightful)

Smallpond (221300) | about 2 years ago | (#42362755)

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.

Long story short... (5, Funny)

beelsebob (529313) | about 2 years ago | (#42362759)

Programmer doesn't like the coding standards that someone else set, decided to whine about it on slashdot.

Yes, having consistent code makes a difference, it lets you make more assumptions when reading code. If you can't manage to even manage to follow a simple style guide, you're probably doing all kinds of other sloppy things that are unwanted in the code.

Man up and spend a little while getting used to it, and using it properly.

Re:Long story short... (1)

pep939 (1957678) | about 2 years ago | (#42362857)

You hit the nail on the head. Another blablablahhh story on slashdot. It's called cooperation people, you can't expect 100+ developers to efficiently work on seceral projects interchangeably without coding standards. And no, it's not the role of the text editor/IDE, it's part of the job.

Re:Long story short... (1)

Anonymous Coward | about 2 years ago | (#42363005)

This this this this!!!!!!

I can not tell you the number of times the one whining about coding standards for some reason just wants to control it.

Knew a guy who rewrote a 2 year project just because he did not like the style I had. Funny how he ended up with the SAME program. My coding standard fit on the back of a napkin and I was pretty flexable about adding/removing things. My only rule was you change the rules you fix all the code to match and like soon. His took 4 pages single spaced and people were fearful of breaking it or listen to him bitch about how they used tabs instead of spaces on the end of a line. Funny too how my code had 1 standard and 3 people worked on it and his had 8 different styles (because he could never make up his mind about any style).

Best complement I ever get from another coder? Your code is easy to read. The ones who 'bitch' about style always inevitably say 'where is my asprin'.

The other one I love is "we are all professionals" which is usually code for "we dont give a damn about the group and are a bunch of cowboys".

Re:Long story short... (0)

Anonymous Coward | about 2 years ago | (#42362933)

I discovered a long time ago that code which I was maintaining which was littered with spelling mistakes in the comments tended to be of lower quality than that produced by good spellers.

Whether that applies only to my limited part of the programming universe, or generalises to the greater world, I can't say.

Re:Long story short... (0)

Anonymous Coward | about 2 years ago | (#42362959)

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. those who learn to use one convention, will find that be forced to write in a different one will make it hard for them to browse through their own code. 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.

I think it's much more important to focus on things such as making sure that local variables are always initialized, and when they're structs they're memzeroed, that no undeclared function is ever called, etc. etc. Most (but not all) these things can be enforced through the use of static analysis tools and compiler flags.

Re:Long story short... (4, Informative)

beelsebob (529313) | about 2 years ago | (#42363097)

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();

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

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.

Re:Long story short... (1)

caywen (942955) | about 2 years ago | (#42363109)

I agree, though "Funny" isn't quite the right mod.

I find that usually when one whines about this kind of thing, the important things the developer should be concentrating on (e.g. how to make things more efficient, how to solve problems, how to maintain better overall code organization, etc) escapes them entirely.

It's the same thing as that annoying C++ dude going around asking other C++ why their code isn't employing functional paradigms more - all the while the product has serious burning issues.

Re:Long story short... (0)

Anonymous Coward | about 2 years ago | (#42363113)

I had something like this happen to me years ago - big company, huge codebase (millions of lines). They had a coding standard and my personal one was very different. I simply learned to work 'their way', while coding 'my way' for myself. At another (smaller) company my boss and I forever differed on our structuring of IF statements - became a watermark of which one of us had last worked on the code! Between 2 people who get along this can become an inside joke, with dozens of developers it can become a nightmare and a strict standard is the only way to go.

OpenStack (0)

Anonymous Coward | about 2 years ago | (#42362761)

Check out OpenStack and their infrastructure tools. For example, they have a trunk gating setup for pep8 and pyflakes for their python code, and it is all opensource and automated.

Eclipse (0)

Anonymous Coward | about 2 years ago | (#42362765)

Just use Eclipse formatter and clean up. Configure all their rules and done.

Re:Eclipse (2)

gantzm (212617) | about 2 years ago | (#42363191)

I don't think you know what a "coding standard" is. It's not just formatting.

Re:Eclipse (2)

DickBreath (207180) | about 2 years ago | (#42363195)

Yes. Good. And Eclipse helps format your code as you type it.

But . . .

You can still have format wars, but automated and invisible, and probably inefficient for the source control system. So everyone needs to import the same formatting settings into their copy of Eclipse. Or make that file part of the project.

There is or should be more to coding standards than mere style. How about things like making methods static if possible. Not making something public unless there is a reason. Keeping local variables within the smallest possible scope, etc.

Some of those kinds of rules really CAN have productivity gains for other programmers who have to read and comprehend code written by someone else.

Yes, it really does. (1)

Anonymous Coward | about 2 years ago | (#42362769)

The fact that you're even asking this question shows you've never had to deal with maintaining code which was written without regard for a consistent coding style. Deal with conforming to a coding style, and get back to us when you have a bit more experience in the real world.

+1 insightful, disagree (1)

chadenright (1344231) | about 2 years ago | (#42362771)

I lost about three days of productivity on a new programming language (the Asterisk extensions.conf stuff, actually) because it turns out that that particular language treats whitespace after a comma in a function call as part of the passed parameter. A wonderful example of a language enforcing a language standard -- you cannot put a space after your commas, or the language will break. I only wish it had been documented a little bit better. On balance, though, I would argue that that's a perfect example of a very good reason NOT to strictly enforce coding style.

Re:+1 insightful, disagree (1)

bzipitidoo (647217) | about 2 years ago | (#42363065)

Asterisk is a mess. Weird, idiosyncratic syntax that changes from version to version, poor documentation, and a lack of capability. You can program in the stuff, but it's not easy. It's a good cure for people who hate Perl and shell scripting. After struggling with crap like Asterisk, if you don't long for something better like Perl, you aren't a programmer.

Re:+1 insightful, disagree (1)

93 Escort Wagon (326346) | about 2 years ago | (#42363069)

I lost about three days of productivity on a new programming language (the Asterisk extensions.conf stuff, actually) because it turns out that that particular language treats whitespace after a comma in a function call as part of the passed parameter.

Sounds like the PHP developers have been doing a little moonlighting for that project.

Christmas story (-1)

Anonymous Coward | about 2 years ago | (#42362775)

A slashdotter reads this post. Suddenly the Troll mounts him from behind.
Slashdotter soon passes out, out of excitement.
Then the Troll mounts another slashdotter, but meanwhile first slashdotter wakes up,
and demands more.
The Troll then fucks them both in Round-robin with variable time quantum fashion, until they
both pass out again.

Mod this post down, if you are begging the Troll to fuck you too.
Mod this post up, if you want the to fuck the Troll.

And mod it sideways ... (0)

Anonymous Coward | about 2 years ago | (#42363099)

... if you can't spot the troll.

It's your responsibility. (5, Insightful)

pclminion (145572) | about 2 years ago | (#42362781)

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.

Consistent Style Is Important (1)

Anonymous Coward | about 2 years ago | (#42362789)

Keeping a consistent style is important. If you are part of a larger project, then there needs to be a cross-project standard. I cannot say whaich practices/standards are best. You just need to have one.

Some things do, but not those issues (2)

AuMatar (183847) | about 2 years ago | (#42362791)

Things like using solid variable/function names, providing sufficient (and quality) comments, and keeping similarity in architectural style matter. How many spaces you use (as long as you use some indentation) or what style of variable names you use makes no difference. And anyone who brings it up in a code review should be shouted down- the purpose of a code review is to find bugs, missed corner cases, unintended consequences of a change, and to find alternate ways to solve a problem. It is not there for cosmetic issues, and anyone who brings them up is wasting time for no gain and makes the code reviews of the entire organization less useful.

Yes and no (1)

davidwr (791652) | about 2 years ago | (#42363125)

If the stylistic issues are likely to cost significant effort down the road, they need to be brought up.

It may be better to bring them up 1-on-1 with the developer, but they need to be brought up.

On the other hand, if "non-standard" stylistic issues won't cost significant effort down the road, then I agree, drop it.

Entitled Aspie (0, Funny)

Anonymous Coward | about 2 years ago | (#42362793)

From the summary:

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

Aww, baby is whining about inconvenience because baby wants to do things only baby's way even though there are guidelines and standards to follow. baby doesn't like to conform to standards other than his own, even if it means that everybody else loses hundreds of hours having to adapt to his style--which they won't, for long if baby keeps being difficult and stubborn.

-- Ethanol-fueled

Tools support (3, Informative)

K. S. Kyosuke (729550) | about 2 years ago | (#42362795)

We live in the future, why don't our tools enforce these standards automagically?

man gofmt

Of course it's a good idea. You wouldn't want to read a book printed wholly in italics, now would you? It's not that it's impossible to get used to it, only we got un-used to it and standards are useless unless you cling onto them at least for a while.

I see the problem right there (3, Funny)

davidwr (791652) | about 2 years ago | (#42363173)

man gofmt

In many shops, this will generate an error:

'man' is not recognized as an internal or external command,
operable program or batch file.

OT .sig (1)

davidwr (791652) | about 2 years ago | (#42363197)

Ezekiel 23:20

LOL, talk about taking things out of context!!!

following standards (1)

Anonymous Coward | about 2 years ago | (#42362797)

If you can't code to published standards, what makes you think your algorithms are any better?

Naming, sure. Whitespace? No. (5, Insightful)

TheNinjaroach (878876) | about 2 years ago | (#42362799)

Consistent naming is important. It lets you quickly call into libraries that other people have written without having to double check, "was that camel cased or underscored spaced?"

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.

Re:Naming, sure. Whitespace? No. (0)

Anonymous Coward | about 2 years ago | (#42362973)

maybe, but it's not THAT hard to get right, you just run the code through the style checker, and have it correct errors.

You DO have an automated style-checker, right?

Re:Naming, sure. Whitespace? No. (2, Insightful)

Anonymous Coward | about 2 years ago | (#42363079)

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:Naming, sure. Whitespace? No. (1)

Anonymous Coward | about 2 years ago | (#42363085)

But nit-picking over whitespace is simply annoying.

you, borther
These whitespace rules in english are also very

Re:Naming, sure. Whitespace? No. (0)

Anonymous Coward | about 2 years ago | (#42363121)

Internal whitespace can be nit-picky, but indentation at the left margin makes a huge difference for readability. (Of course, if you're working in Python, it's proper syntax to start with.)

I've just spent the last two weeks dealing with a PL/SQL procedure I've never worked on before, full of nested sub-procedures, none of it adequately documented or commented. The indentation was as chaotic as a seismograph during a small earthquake. I didn't have time to refactor anything, but I did take the time to fix the indentation so block scopes would be clearer. It is far easier to find the matching END; on a procedure 3 levels deep when everything within the loop block is properly indented.

If not, why do we have them? (1)

mcgrew (92797) | about 2 years ago | (#42362801)

It's like reading slashdot. You come across someone who can barely spell, has trouble with homophones, puts extraneous apostrophes in, and it makes it much harder to read for someone who is used to reading. The same goes for coding. If the reviewer sees a bracket where he expects a curly brace, even though the two are interchangable, it's going to slow him down.

Plus, if you used three spaces instead of a tab, what other errors are in your code?

IDE's can enforce these standards (0)

Anonymous Coward | about 2 years ago | (#42362803)

At least eclipse has some xml files. Also checkstyle exists.

What IDE are you using? (2)

decipher_saint (72686) | about 2 years ago | (#42362805)

I ask because in the last 5 years I've been using various flavours of Eclipse and Visual Studio and both of them come with document formatting features that you can template.

The only thing I ask people if they plan on formatting a document during a change is to do it either before or after their change so I can review the differences more easily in source control revision history.

Oh and to answer the question, yes, I've found if the team can adhere to vaguely common style they can navigate their way through our entire codebase without getting lost in one individual's style preference.

Obviously YMMV in this regard.

Is it meaningful to measure seconds. (1)

will_die (586523) | about 2 years ago | (#42362807)

Ok you may spent an hour or more setting up the code beautifier with the rules but after that what does it take a min or so at most to be run?

reading (0)

Anonymous Coward | about 2 years ago | (#42362813)

working with a bunch of developers who all have very different coding styles, its much much easier to read code when it is all in the same format.
I would imagine this is especially true for management that may have some coding background, but aren't hardcore devs.

It's about conformity, not code (1, Insightful)

crazyjj (2598719) | about 2 years ago | (#42362821)

It's a test on following orders and attention to detail. We don't need any of you rogue coders 'round here, see?

Obfuscation by Script (1)

lowsix (60516) | about 2 years ago | (#42362823)

I'll bet we could fairly easily construct a perl/awk/python script that will convert between the two, assuming one isn't already in standard use. Sounds like a waste of time to worry about it to me.

PSR (1)

diemuzi (940206) | about 2 years ago | (#42362829)

Coding standards makes quite a bit of difference. If I'm going to review the code you've supplied me with I'd better be able to clearly read and understand what you are doing. I'm a big believer / follower in the FIG PSR rules to follow.

Coding standards simplify (0)

Anonymous Coward | about 2 years ago | (#42362837)

Coding standards give useful hints as what the other person is trying to do. Yes it can get very silly but when you are tired and working on a tight deadline to fix a critical bug in someone else's code every little bit helps.

Write a pretty print! (3, Insightful)

jackb_guppy (204733) | about 2 years ago | (#42362849)

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!

Stop whinging (0)

Anonymous Coward | about 2 years ago | (#42362859)

Stop whinging and do your job properly, so whoever comes in after you can get on with their job and won't feel the need to post your shithouse code to

Yes, but impractical for humans to enforce ... (1)

JSkills (69686) | about 2 years ago | (#42362877)

Rather than attempt to get various teams of developers to code in one exact style, we decided on implementing a single standard for coding but to automatically enforce it via a pre-commit hook when someone checks in their code into our repository. That way, managers don't have to waste their breath attempting to micromanage the minutia of where the semi-colons go, developers can be free to work how they're most comfortable, and when you check code out you can always expect it to be in the exact same familiar form.

This seems to have given us the ability to benefit from a single coding standard for what's in our code base, while *not* spending any developer or manager time to have to worry about it getting/keeping it that way ...

coding style can get you fired (3, Informative)

TheGratefulNet (143330) | about 2 years ago | (#42362887)

happened to me. at a large networking company (I don't want to mention the name, for various reasons) I felt more comfortable with my own coding/indenting style, which included lots of whitespace (my eyes are old and the extra vertical WS helps isolate 'paragraphs' from each other and that clustering really helps me a lot).

my boss felt so strongly about it, though, that he'd constantly use that as a way of beating me up. eventually, I got fired and I think our conflict was a major part of that.

I have been coding for over 35 years (in C, mostly) and I have a damned good handle on how to code for readability and supportability. but when it comes to styles, the guy in charge wins, no matter what, even if there is no right answer, per se.

you should not code in a radically different way from the existing codebase, but to complain about line length (at the time, they were HARSH about keeping lines to 80chars max, which was so braindead) and my vertical whitespace just really ticked one or two people off enough that they complained and got me canned.

so, yes, those that want to pick fights, will do so over stupid little things and make a big damned deal about it, too. part of 'coding politics' I guess. large and small companies all have this problem and it won't ever go away.

better companies can be flexible. the more rigid ones, I find, have lost their way. writing code is not a mechanical thing; there's an art to it and to strip all individualism from the task is just plain wrong, to me.

Good ol indent (0)

Anonymous Coward | about 2 years ago | (#42362891)

For my C projects, I love "indent -kr -ut -i8 -l120 -lc120 -sob -bad -bap"
Makes any C code instantly readable to me :)

Most Java shops I've worked automate code style (5, Informative)

neiras (723124) | about 2 years ago | (#42362907)

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.

Re:Most Java shops I've worked automate code style (0)

Anonymous Coward | about 2 years ago | (#42363103)

Buy-in is the biggest part of the problem with some people; oh, and the previous manager decided he wanted to make all the devs happy by letting them use whatever tools they wanted, and we ended up with five different IDEs which each have their own ideas about auto-formatting.

Re:Most Java shops I've worked automate code style (2)

blackcoot (124938) | about 2 years ago | (#42363161)

We do this in C++ and Python for all our projects now. All in the repo commit hooks.

Coding standards matter and are trivial to fix (1)

Purpendicular (528740) | about 2 years ago | (#42362921)

Code Complete by Steve McConnell discusses this. It is not your code, it is the company's code, the team's code. Some poor bastard will need to read this code five years from now. All you need to do is to use for example astyle or uncrustify to automatically format all code, before it is even accepted for a code review. Correctly formatted code, by a computer, should be a prerequisite. If the code is not correctly formatted, call of the inspection/review and meet again at some other date.

IDEs (1)

Githaron (2462596) | about 2 years ago | (#42362923)

Most IDEs have the ability to auto-format existing code. They also let you change the formatting rules if you prefer something different than the default. Your organization can just share formatting rules file. Code the way you want then hit the hot key before committing.

Yes for Large or Multi-Dev Projects (1)

detain (687995) | about 2 years ago | (#42362925)

When you have many people working on the same code base coding standards are very important. Its impossible to keep every line of code fresh in your memory so when viewing your code or someone else's, quickly identifying what each part of the code does is very important. Knowing even something as simple as a standard variable naming convention used in a program can make the difference between jumping into a block of code and accurately modifying it or butchering it.

Fix your tools (0)

Anonymous Coward | about 2 years ago | (#42362941)

What's wrong with your toolchain that it isn't dealing with most of this?

Your editor should be indenting properly and doing the right thing with tabs-versus-spaces. If it isn't, poke around in the config properties until it is, or get a copy of emacs, which I guarantee can be customized to do whatever crazy thing your company demands.

pylint (if you use python), or whatever the corresponding tool is in your language-of-choice, should be easily configurable to whine about errors like "this function is more than two hundred lines long, you should break it into smaller pieces", or "line contains over 150 characters, should be wrapped", or whatever. I've seen similar tools for c, java, etc.

Nearly every coding style guideline I've seen except camelCase versus underscored_names should be entirely catchable by an automated tool; it should be run as part of your compile process (or unit test process or whatever), so these bugs should never be getting as far as the human pedant in your code review. And variable/function names being in camelCase or whatever should be second nature to you after a week on the job.

If your toolchain can't deal, talk to your manager until you can shake free a few days to write an automated tool to add to your toolchain! Your coworkers will thank you, you'll get some experience with scripting...

Set up 'indent' or other auto-indenter (0)

Anonymous Coward | about 2 years ago | (#42362943)

In my last job, they passed out a file so that Eclipse would automatically set up the company default indentation (and most other features.) Easy.

There's plenty of code beautifiers out there.Just pick one.

Cries from a sloppy coder (0)

Anonymous Coward | about 2 years ago | (#42362945)

If the comments on the review begin with coding style chances are that you haven't read the patch well enough yourself, otherwise you would have spotted them (and subsequently other possible problems) yourself. It's a sign of a tidy programmer, someone who attends to detail, and as such, it's an excellent self-review of your patch before handing it over to others. On the other hand, it's really something your editor should handle for you, if it doesn't you need to become better friends with it or change to something more powerful.

I use Eclipse and CheckStyle (0)

Anonymous Coward | about 2 years ago | (#42362949)

Yes, they're important. Code styles are as different as handwriting. One person may write with all capital letters, another may use capitals and lower case, someone else may use cursive, another may use a mix of cursive for some letters and print for others. Now imagine having a handwritten book with five different writing styles all mixed up. It makes is far more arduous to read than if you had one consistent style. The key here isn't WHICH style is used. It's that ONE style is used, all the time.

It sounds like your problem isn't that code style fascists are picking on you. It's that you don't use any tools to automatically format your code for you in such a way that everyone on your team has the same style. Our department has specific code style definition files which are used by Eclipse and Maven. These ensure that the style is consistent, and we don't commit a 50-line code update when only one line was a code change, and 49 lines were formatting junk. Having everyone use the same style definition files is important. You don't want your commit log to be cluttered with formatting junk. That makes it nearly impossible to use SVN logs and 'blame' to determine when a piece of code was changed, and why, so you can avoid fixing one bug in a way that creates five more.

It spares me from headaches (1)

Kergan (780543) | about 2 years ago | (#42362953)

Grammars and spelling came about in the 16th century or so, for much the same reason. Yud probbabli minde iff I rote anglich zis wai bekoz youd spend wai tu moch tim vonderrin wat I rote. If you think I'm exaggerating, try reading old English manuscripts -- or worse, old French manuscripts.

Embrace the coding standard, and enforce it for the next guy's sanity when it comes to maintenance. Ideally, setup pre-commit filters on your repo: if the code doesn't conform to the in-house standard, the repo should reject it; period, end of story. That way, nobody wastes time on it except those who aren't respecting them in the first place.

Another already suggested that nothing beats clear thinking. I agree, but don't dismiss how consistency in code formatting improves code readability and maintainability.

conFORmITY leaDS to BetTER READaBiLITY (1)

realStrategos (260587) | about 2 years ago | (#42362961)

Conformity makes things easier to read; It depends on how extreme the grammer nazis go. The question is how much does it really matter that i used lowercase i's or incorrectly used a semicolon ... it depends on the context.

My thoughts (1)

Synerg1y (2169962) | about 2 years ago | (#42362967)

I think it's not so much to encourage good practice and ensure standards, as it is to discourage bad practices that are very hard to standardize later. In fact, in newer versions of Visual Studio, when you rename a variable, it gives you the option to rename everywhere else the variable is referenced. That feature probably originated out of these standards. I don't care if you name your variable studentScore, studentscore, or StudentScore, but if you name it StudentS, ss, Sscore, please die, thanks.

Simple answer: it depends! (1)

aglider (2435074) | about 2 years ago | (#42362979)

It depends on what else is going to be put on the table.
A uniform, ubiquitous, documented coding standard can be of great help.
But it's still just a help or a tool, not a solution.
You still need to know how to effectively program, you have to get a fairly good knowledge about the underlying system, the environment and, of course, the problem the program is meant to solve.
I would say it's just like following a precise order in company bookkeeping.
It helps a lot, but you still need to follow the rules and the law.

Standards are good, (2)

Nuitari The Wiz (1123889) | about 2 years ago | (#42362983)

That's why everyone has their own...

There are some standards / practices that are very important when it comes to making secure code. They avoid basic mistakes and so on. There should also be some minimal enforcement in terms of how to indent which always help to reread the code. Peer review for anything complex is also a good practice.

As for camel case, or hungarian notation, I feel that they are mainly a waste of time in the best of case. Being pedantic about code isn't going to help anyone or any project, in fact it might make a lot of talented people leave the company.

Yes, it matters (0)

Anonymous Coward | about 2 years ago | (#42362993)

As someone who has come into a variety of long-standing projects and found the developers who worked before me did not have a set coding style I can definitely tell you it matters. It doesn't really matter which coding style the developers standardize on, but it matters that you have one. it is a pain switching between different styles, different approaches to comments, different naming conventions, tabs vs spaces.

Once I remember surprising a manager who had originally hinted that I was the second developer on a project when I told her I knew I was, in fact, the forth to work on the project. When asked how I knew I pointed out there were three existing distinctive code styles scattered through the code and none of them really meshed elegantly.

Think of it this way, would you want to read a book/document that was hand written in three different styles? Especially if the lines alternated? It would be hard to get into the flow. The same applies for programming code.

Really? (0)

Anonymous Coward | about 2 years ago | (#42363033)

Wow, i hadn't expected the anally retentive crowd to be so big.

Since IDEs these days have loadable code-formatting rulesets it's as easy as having some simple rules in your project.

A - This is the formatting ruleset, it's checked in, use it
B - If you don't like it, make one for yourself, check it in and use it
C - If you open someone's code and you feel your bum muscles tighten up, just pick your personal ruleset and press Shift+Ctrl+F (or whatever does it in your IDE)

And most important, NEVER talk to the project-manager (that would be me) about coding style.
Invest the whining time in writing your ruleset and give me a brake.

Saves a full man-month in a big project.

It helps (5, Informative)

Cro Magnon (467622) | about 2 years ago | (#42363035)

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.

I'm a bit surprised by the question (1)

_Lint_ (30522) | about 2 years ago | (#42363041)

Most modern programming environments do enforce coding standards. We use Eclipse, and have project-wide format standards. As for it being a 'coding standard': I've always considered coding standards and formatting standards to be different things. Code reveiws are for coding standards, not for picking nits on whitespace. That said, you don't submit your code for review until you feel it's ready to submit it to the revision control system, so i don't know why you still have whitespace issues in your code.

Re: I'm a bit surprised by the question (1)

_Lint_ (30522) | about 2 years ago | (#42363053)

Opps. when I said "Most modern programming environments do enforce coding standards" i *meant* that they enforce *formatting* standards.

You should code in Google's "Go" language (0)

Anonymous Coward | about 2 years ago | (#42363045)

We live in the future, why don't our tools enforce these standards automagically?"

The Go developers specify an official coding style standard, and they provide a tool to rewrite your source according to their standard. They heavily encourage everyone to automatically run all source through the tool on each checkin. Their FAQ has a kind of amusing take on the issue, which says something like: "You may not like our coding style, but no style is inherently better than any other. Consistency more important than any personal style preference. So deal with it."

No studies (1)

nicoleb_x (1571029) | about 2 years ago | (#42363047)

Of course there are no studies because everybody just KNOWS it matters.

I switch between javascript, C#, html and sql all day long, and once in a while some php. I can even deal with minified javascript if I have to.

I got your "reachable chunk" right here... (1)

Impy the Impiuos Imp (442658) | about 2 years ago | (#42363049)

Coding standards are to reduce the chance of bugs. They are not bugs per se.

Coding reviews are worthless in most situations. People look for coding standards violations more than they do for the error the standard is trying to prevent.

Tools should be written not just to look for violations, but wherever possible, look for the bug the standard is trying to prevent.

I also recall humerous "dualing checkins" where two guys, using different tools, kept overriding each other's coding standard fixes.

One kept adding a default case to a switch because the standard demands it. The other kept removing it because it was flagged as unreachable because all possible cases had been handled already.

You wasted valuable company time (0)

Anonymous Coward | about 2 years ago | (#42363061)

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

Actually your coworkers lost hundreds of hours in code reviews because you were sloppy and did not care about your code being readable. You should fix your code before even bothering them about a review.
Strict coding styles are good because when they are enforced you spend zero time wondering how to name variables or format code. You spend time actually writing good, readable code. This StackExchange question [] has a lot of insight on the topic.

What IDE are you using? (1)

wesleyjconnor (1955870) | about 2 years ago | (#42363075)

If it doesn't have an auto format you can tailor to the company standard get one.
Alt shift f is your friend...

I'm Surprised It Took So Long to Front Page (2)

ios and web coder (2552484) | about 2 years ago | (#42363111)

I saw this story very early this morning.

Regardless of the reason for it being posted, it's a good conversation to have.

I think that consistent coding style is extremely important. There's a heck of a lot of sacred cows and third rails out there, when it comes to exactly what those coding styles should be. I'm not comfortable dictating to others what is best. I think that is likely to defeat the purpose.

Unless you feel like nursemaiding your own code for the entirety of your career, then using a consistent style is directly to your own benefit, as that means that you can easily turn it over and move on to newer, more interesting things.

In my own experience, developing a style (which includes commenting) is something that quickly becomes rote. You don't even think about writing good code. It just happens.

Pascal was developed as a teaching language. It enforced a certain level of style. Python enforces it even more, by doing things like insisting that whitespace be spaces, and that indents make a big difference in terms of context and scope.

When I became a C programmer (after using Pascal), my style quickly degenerated into Caveman Gothic. I had to re-learn a decent style.

What helped me a lot, was using Doxygen [] . It's a fantastic utility that helps turn comments into documentation. I had used HeaderDoc and JavaDoc before, but they never caught on in my workflow. Nowadays, pretty much everything I write is Doxygen-commented. I actually feel physically uncomfortable when I write code without Doxygen comments (like a quick one-off test function).

Working on a team helps. Having someone come over to you every two minutes, asking the most simplistic questions, trains you to write "leave me alone" code.

Once you've been writing consistent code style for a while, you don't even think about it. Even my quick n' dirty routines are extremely well-structured.

I have a certain style, which involves things like function and class names, variable and data member names, indenting, use of certain language primitives, etc. It is not ironclad, but I find it flows pretty naturally.

You do have tools... (0)

Anonymous Coward | about 2 years ago | (#42363141)

Ever heard of indent and similar?

Just configure them specifications of the project, write your code however the hell you want, and run indent to clean it up before submitting.

Wont help you for naming conventions, though

One day, and it won't be long (1)

caywen (942955) | about 2 years ago | (#42363145)

One day, if you work hard enough and get your stuff done, if you impress people with dedication and skill all the while letting the unimportant things flow as water under the bridge, you will get to make the rules. And when you do, I hope to see you asking Slashdot in a new context.

The objective... (3, Informative)

blackcoot (124938) | about 2 years ago | (#42363155)

Is to achieve this: [] -- make things that are wrong be more obviously wrong. Using discipline and coding standards is just one part of the appropriately paranoid developer's defensive programming toolkit.

Yes (1)

Ziggitz (2637281) | about 2 years ago | (#42363157)

Coding standards are important. What you're describing is much more code formatting, most decent IDE's can accept coding templates that will allow the auto format feature to conform to your company's formatting standards. When I think coding standards I think, defensively checking for null values, not chaining method calls, always using braces with if statements for java users and keeping code complexity as low as possible while meeting the requirements. The goals of coding standards are to keep code human readable and avoid common pitfalls of bad coding habits. Besides, you should take pride in your written code and make it as presentable as possible.

Tools, tools, tools (0)

Anonymous Coward | about 2 years ago | (#42363171)

Last time I had to do this, the "Official Coding Style" started with, "Use the supplied formatting XML file and keep the files in that format." Which, solves all the issues of spacing and braces and what-not. This makes it easier to read. And it keeps the version control free of dueling developers checking in bunches of formatting changes along with the interesting code changes. Of course, they get changed back when the other guy makes changes in there. (You could fix this if the "diff" tools, whether supplied with the version control or not, were smart enough to ignore superficial formatting changes but I can't imagine how the display would effectively show real changes in the midst of the formatting changes it was ignoring. Fortunately there are people smarter than me to figure that out.)

Added a little about questionable or confusing coding practices like using a variable for two or three things or over-factoring or doing things in a complex and possibly "faster" manner when you don't know that the simple way is too slow. You know the drill. Suggested the use of good sense.

Then I got down to the part about naming conventions, etc. Stuff like using English verbs and nouns in the right places in the names. Avoiding abbreviations and shortened forms of words, mostly. Comment as much as necessary and as little as possible because the code explains itself. (Oh, and, you have to make the code do that, too.) Keep the blocks of code small enough to mostly see on a single screen. Trying to imagine yourself reading the code in two or three years (or heavily sedated) and being able to understand it. (There are tools that can do this for specific languages but they take time to get set up so they yield interesting reports and I haven't figured out whether its worth the time or not. Flagging something as needing a fix when it really doesn't is such a pain.)

Use a script or a tool to reformat the code (1)

LordZardoz (155141) | about 2 years ago | (#42363187)

Pretty much everyone here has already said it. Coding standards to help productivity, but its a group thing. ie: its more of a a +3% to +5% gain for everyone who has to share code and know what the hell is going on. Coding to a standard that is not a habit for yourself is going to be a bit of a hit to your own productivity.

So if you hate dealing with the existing code standard, you could either implement a script to do the reformatting for you, or you can find an existing tool to do the same. Write however the hell feels natural, and when its working, run the conversion script and retest. If possible, convert in both directions (ie, go from official standard to your preference before you start modifying it again). It wont help structural issues (ie, if using certain design patterns is forbidden), but it will deal with the camel case vs underscore, variable name prefixes, space vs tab, and where the hell to put curly braces.


Load More Comments
Slashdot Login

Need an Account?

Forgot your password?