Ask Slashdot: Do Coding Standards Make a Difference?

← Back to Stories (view on slashdot.org)

Ask Slashdot: Do Coding Standards Make a Difference?

Posted by Soulskill on Friday December 21, 2012 @07:25AM from the everybody-do-it-wrong-the-right-way dept.

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

74 of 430 comments (clear)

Min score:

Reason:

Sort:

After 42 yrs programming I say... by rs79 · 2012-12-21 07:28 · Score: 5, Insightful

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

--
Need Mercedes parts ?
1. Re:After 42 yrs programming I say... by man_of_mr_e · 2012-12-21 07:48 · Score: 5, Interesting
  
  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.
  
  --
  If you need web hosting, you could do worse than here
2. Re:After 42 yrs programming I say... by gantzm · 2012-12-21 07:53 · 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.
  
  --
  
  Excessive forking causes un-wanted children.
3. Re:After 42 yrs programming I say... by DickBreath · 2012-12-21 07:54 · Score: 2
  
  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.
  
  --
  
  I'll see your senator, and I'll raise you two judges.
4. Re:After 42 yrs programming I say... by Decameron81 · 2012-12-21 07:56 · Score: 5, Interesting
  
  THE reaSON WHy coDiNg standards_exist is thatTheyIncrease THE_REaDABILITY oF YOur cODe.
  
  --
  diegoT
5. Re:After 42 yrs programming I say... by casings · 2012-12-21 07:59 · Score: 3, 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.
6. Re:After 42 yrs programming I say... by BasilBrush · 2012-12-21 08:00 · Score: 5, Insightful
  
  Most diffs can ignore whitespace...
  I don't understand your second point.
  You didn't understand his first point.
7. Re:After 42 yrs programming I say... by Anonymous Coward · 2012-12-21 08:08 · Score: 3, Funny
  
  You're probably the finicky person who keeps complaining about my rot13 variable names. To each their own, buddy.
8. Re:After 42 yrs programming I say... by casings · 2012-12-21 08:09 · 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.
9. Re:After 42 yrs programming I say... by blackm0k · 2012-12-21 08:12 · Score: 5, Insightful
  
  Not to name and shame, to know who to ask about what they were exactly they were doing when they changed that bit of code. You know, so my fix doesn't break there changes.
10. Re:After 42 yrs programming I say... by IAmGarethAdams · 2012-12-21 08:14 · Score: 2
  
  What if you have one coder using project_cost and another using projectDeadline, and this lack of consistency is continued across the whole set of functions and variables in the project?
11. Re:After 42 yrs programming I say... by IAmGarethAdams · 2012-12-21 08:15 · Score: 5, Funny
  
  (I know, I know, it means you must be a PHP developer)
12. Re:After 42 yrs programming I say... by Decameron81 · 2012-12-21 08:18 · Score: 4, Informative
  
  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
13. Re:After 42 yrs programming I say... by UnknownSoldier · 2012-12-21 08:27 · 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 ) , just as long as EVERYONE follows them.
14. Re:After 42 yrs programming I say... by Anonymous Coward · 2012-12-21 08:28 · Score: 3, Interesting
  
  I have a coding standard. The coding standard is,
  1. use tabs for indentation, spaces for alignment.
  2. put a space after a comma
  Basically, so shit is readable. There are coding standards for English too. That you put a space after punctuation and that you start a sentence with a capital. Yeah, people still fuck up grammar. They still write run-on sentences. They still can't spell.
  There is nothing special about code that hasn't already happened in regular languages. Having a simple, easy to follow coding standard is OK. Being over the top is a little unproductive but then it depends on the size of the project. There may be a different rigor when adhering to your workplace's coding standard vs. something like Linux kernel.
  So yes, coding standards make a difference if there is more than 1 developer involved.
15. Re:After 42 yrs programming I say... by daenris · 2012-12-21 08:37 · Score: 3, Insightful
  
  You assume that formatting refers only to whitespace, but given the larger context of the conversation, I believe he's using formatting to refer to the whole of the standards (variable name conventions, spacing, brace position, etc).
16. Re:After 42 yrs programming I say... by zakkudo · 2012-12-21 08:54 · Score: 2
  
  When someone makes a generic list of bullets, only some of them may apply to you. Some of them may have been made from experience in different situations or time periods.
  It tends not to be constructive latching onto a single bullet screaming "It doesn't apply to me!!!" over and over and over again.
17. Re:After 42 yrs programming I say... by casings · 2012-12-21 08:54 · Score: 3, 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.
18. Re:After 42 yrs programming I say... by luis_a_espinal · 2012-12-21 09:12 · 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.
  
  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.
19. Re:After 42 yrs programming I say... by mk1004 · 2012-12-21 09:12 · Score: 2
  
  We live in the future, why don't our tools enforce these standards automagically?
  They would, but they are held up in code review.
  
  --
  I can mend the break of day, heal a broken heart, and provide temporary relief to nymphomaniacs.
20. Re:After 42 yrs programming I say... by VortexCortex · 2012-12-21 09:55 · Score: 4, Informative
  
  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.
21. Re:After 42 yrs programming I say... by lgw · 2012-12-21 10:08 · 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.
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
22. Re:After 42 yrs programming I say... by Fastolfe · 2012-12-21 10:31 · Score: 4, Informative
  
  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.
23. Re:After 42 yrs programming I say... by Anonymous Coward · 2012-12-21 11:54 · 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 ) , 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.
24. Re:After 42 yrs programming I say... by UnknownSoldier · 2012-12-21 12:55 · Score: 3, Informative
  
  Yes, agree 100% !
  Simple example:
  
  const int SIZE = 256; // all constants are upper case #define ALIGN_DOWN(n,pow2) (n & (pow2-1)) // all macros are upper case with underscore in-between words class CContainer { // Classes are prefixed with 'C' int m_size; public: int getSize() const { return m_size ; } // Coding standard will mention about Brace Style and the case style. (Are one-liners getters allowed?) }; enum EFlags { // Enums/flags are prefixed with 'E' FLAG_READ .= (1 << 0), FLAG_WRITE = (1 << 1), FLAG_EXEC .= (1 << 2); }; // Ignore the periods since /. doesn't know how to keep extra whitespace in code. :-(
25. Re:After 42 yrs programming I say... by TheLink · 2012-12-21 17:32 · Score: 2
  
  Brace position and spacing both are encompassed by the whitespace argument that I was referring to.
  
  ORLY? Which diff are you using treats the following as the same?
  if (a==b) {
  doSomething;
  }
  As this:
  if (a==b)
  {
  doSomething;
  }
  As for ignoring whitespace, just hope you never inherit a python project that's written by multiple people who don't follow the same standards ;).
  --
  
  Too many replies beneath your current threshold
26. Re:After 42 yrs programming I say... by allo · 2012-12-22 01:19 · Score: 2
  
  the m_ convention is pure bullshit. Every good editor shows member variables in another color. That's it!
27. Re:After 42 yrs programming I say... by DrVxD · 2012-12-22 03:52 · Score: 3, Informative
  
  CodingStandardsThatMandateCamelCaseDecreaseReadability.
  coding_standards_that_mandate_underscores_increase_readability.
  
  --
  Not everything that can be measured matters; Not everything that matters can be measured.
28. Re:After 42 yrs programming I say... by BobVP · 2012-12-22 07:37 · Score: 2
  
  And some developers are color blind, rendering that fancy editor coloring useless.
29. Re:After 42 yrs programming I say... by lsatenstein · 2012-12-22 10:25 · Score: 2
  
  I program mainly in good old C, and I use camel case. If anyone looks at my code, they will see paragraphs, (white space between different functionality). I also tend to run indent before I save the code for the production compile.
  Furthermore, I have a change log at the top of the source, and if the code has many lines, I put in an english description of what that group of functions is supposed to do.
  Sometimes I put in warnings near a code segment as reminders that some logic is there for a good reason.
  50 years in IT and I learned well from my peers. Now I am the one who they follow.
  
  --
  Leslie Satenstein Montreal Quebec Canada
"a net productivity gain"..YES by who_stole_my_kidneys · 2012-12-21 07:29 · Score: 5, Insightful

because when you leave\get fired\DIE, everyone can read your code and not have to interpret it, thus productivity gained.
1. Re:"a net productivity gain"..YES by Anonymous Coward · 2012-12-21 07:47 · 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
2. Re:"a net productivity gain"..YES by mwvdlee · 2012-12-21 07:59 · Score: 4, 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).
  
  --
  Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
3. Re:"a net productivity gain"..YES by Anonymous Coward · 2012-12-21 08:09 · Score: 3, Funny
  
  No. No fucking citation is needed. Go back under the bridge and play with yourself some more.
4. Re:"a net productivity gain"..YES by Capt.Albatross · 2012-12-21 08:35 · Score: 2
  
  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?!
  It's more like they pay people who can only produce confused and confusing code, and then think coding standards will fix the problem.
5. Re:"a net productivity gain"..YES by s.petry · 2012-12-21 08:41 · Score: 2
  
  ^This^! Nothing like going into a shop where everyone was a cowboy and trying to fix what's broken. Fixes that should take minutes take days, fixes that should take days take months, and often enough things need to be completely re-created.
  Yes standards matter.
  
  --
  -The wise argue that there are few absolutes, the fool argues that there are no probabilities.
6. Re:"a net productivity gain"..YES by Anonymous Coward · 2012-12-21 09:00 · Score: 2, Informative
  
  Since I haven't used a goto since the 1980s, except in assembler, I'd love to see some examples.
  And I mean of actual gotos, not similar statements like break and continue.
  Then you may want to look at the linux kernel sometime.
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=mm/vmscan.c;h=adc7e9058181eb4d38c2f22d77bd1e413d3457e7;hb=HEAD#l674
  That lovely function uses a lot of gotos for obvious reasons. Should be obvious why they use all these gotos (there are other examples in that source file)
7. Re:"a net productivity gain"..YES by SourceFrog · 2012-12-21 09:20 · Score: 2
  
  Coding standards decide whether you should do "goto SomeLabel" or "goto someLabel"; they don't prohibit crap code.
  Sure, but in my experience the two tend to go together. It's like, the type of person who holds themselves to good standards in areas of variable naming, is also the type of person who tends to hold themselves to good standards in areas like software design vs spaghetti. The type of developer who is too arrogant and lazy to follow a convention is usually too arrogant and lazy to write decent code. It's about a mindset of professionalism, a clear head, and about taking pride in your work. Some people are professionals who take pride in their work, and this usually reflects in multiple ways.
  Also, the arrogant laziness displayed by the summary poster, he doesn't feel the pain of his own laziness because it is 9 times out of 10 other people who have to clean up after him and figure out what he did. Egotistical gusto about being above it all, is usually the same egotistical gusto that creates a blind spot that doesn't notice that others are cleaning up a mess. The poster talks about "every shop he's worked in", so he's jumping jobs and doesn't see the next guys trying to read his code and scratching their heads, I'll bet money on it.
  Of course, conventions should be functional. I don't give a crap if you do "for (int i=0" or ("for ( int i = 0" for example. But there are some conventions that are simple to follow, and make a huge difference in reading code. For example, "m_" prefix means "member", "g_" means global, and no prefix means a local (stack) variable ... that saves large amounts of time not having to cross-check what is what, you can immediately see from just looking. Trust me, when you have more than just a tiny codebase and start dealing in "real" amounts of code, i.e. hundreds of thousands or millions of lines), then it helps.
  And they go together when cleaning up also. Spaghetti code is a big problem, but if you're cleaning up, then having some useful conventions makes cleaning up spaghetti easier.
  
  --
  My other UID is three digits.
Standards are (Usually) Good by craigminah · 2012-12-21 07:29 · Score: 2

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.
1. Re:Standards are (Usually) Good by Shimbo · 2012-12-21 07:39 · Score: 2
  
  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.
Yes, they do by Anonymous Coward · 2012-12-21 07:30 · 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.
1. Re:Yes, they do by WaffleMonster · 2012-12-21 08:18 · Score: 4, 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.
Don't forget the Terms and Acronyms by Smallpond · 2012-12-21 07:30 · Score: 4, 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.
Long story short... by beelsebob · 2012-12-21 07:30 · Score: 5, Funny

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.
1. Re:Long story short... by beelsebob · 2012-12-21 07:54 · Score: 4, Informative
  
  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.
2. Re:Long story short... by mwvdlee · 2012-12-21 08:06 · Score: 3, 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.
  
  --
  Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
3. Re:Long story short... by Rakishi · 2012-12-21 08:34 · 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.
4. Re:Long story short... by Roger+Lindsjo · 2012-12-21 09:12 · Score: 2
  
  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.
  If they work by them selves, then fine, they can use their own style. However, if they work together, such as drawing one section each of a comic strip or writing separate chapters in a book, then you want them to use the same style. It will be a bit harder on them and they will lose some of their personal style but it will be much easier for the reader. And the same goes for code, I don't really care if curly braces are on the same line or not, if the fields are at the beginning or end of the class definition, but when it varies in the same project or even the same file, then it makes reading and comprehension much harder. And most code that is used has more developer time spent on reading it than writing it.
It's your responsibility. by pclminion · 2012-12-21 07:32 · 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.
Some things do, but not those issues by AuMatar · 2012-12-21 07:32 · Score: 2

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.

--
I still have more fans than freaks. WTF is wrong with you people?
Tools support by K.+S.+Kyosuke · 2012-12-21 07:32 · Score: 3, Informative

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.

--
Ezekiel 23:20
Naming, sure. Whitespace? No. by TheNinjaroach · 2012-12-21 07:32 · Score: 5, Insightful

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.

--
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
1. Re:Naming, sure. Whitespace? No. by Anonymous Coward · 2012-12-21 07:53 · 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.
What IDE are you using? by decipher_saint · 2012-12-21 07:32 · Score: 2

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.

--
crazy dynamite monkey
Write a pretty print! by jackb_guppy · 2012-12-21 07:35 · Score: 3, 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!
coding style can get you fired by TheGratefulNet · 2012-12-21 07:37 · Score: 3, Informative

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.

--

--
"It is now safe to switch off your computer."
1. Re:coding style can get you fired by Salamander · 2012-12-21 13:10 · Score: 3, Informative
  
  The only issue I have is with code diff utilities that don't work well with multi-monitor setups.
  
  You should try to appreciate that not everyone shares your circumstance. Sometimes the most senior developers on a project might have to review code while on the road, e.g. visiting customers or presenting at conferences. Not too many laptops have multiple monitors, and you wouldn't want to carry one if it did. Some of the very latest have pretty decent resolution, but they cost a lot more and they have a very fine dot pitch so the number of characters doesn't scale up as much as the number of pixels. Under those circumstances, code that doesn't display well in a *side by side* diff on a single small-ish monitor is a more serious issue than the junior developer's fetish for super-long lines. Eighty columns might not be the absolute best width, but it's in the range that makes such diffs under such circumstances productive, and it's a width that a lot of people (and tools developed over the last few decades) can handle reliably.
  Also, people who study reading have known for half a century that long lines are hard to scan accurately without a saccade leaving the reader's eyes on the previous or next line, which means that they're bad for readability even on wide monitors. There's a reason newspapers used to set type in columns instead of all the way across the page. You'll need a much better reason than personal aesthetics to do something that's bad for readability and a pain for other members of your team. Without such a reason - and I haven't seen any, anywhere in this thread - that's just selfish and immature.
  
  --
  Slashdot - News for Herds. Stuff that Splatters.
Most Java shops I've worked automate code style by neiras · 2012-12-21 07:38 · Score: 5, Informative

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.
1. Re:Most Java shops I've worked automate code style by blackcoot · 2012-12-21 08:00 · Score: 2
  
  We do this in C++ and Python for all our projects now. All in the repo commit hooks.
Standards are good, by Nuitari+The+Wiz · 2012-12-21 07:44 · Score: 2

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.
Ya to me sounds like "I'm special" syndrome by Sycraft-fu · 2012-12-21 07:48 · 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.
1. Re:Ya to me sounds like "I'm special" syndrome by postbigbang · 2012-12-21 08:07 · Score: 4, 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.
  
  --
  ---- Teach Peace. It's Cheaper Than War.
It helps by Cro+Magnon · 2012-12-21 07:49 · Score: 5, Informative

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'm Surprised It Took So Long to Front Page by ios+and+web+coder · 2012-12-21 07:55 · Score: 2

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.

--
"For every complex problem there is an answer that is clear, simple, and wrong."
-H. L. Mencken
The objective... by blackcoot · 2012-12-21 07:59 · Score: 3, Informative

Is to achieve this: http://www.joelonsoftware.com/articles/Wrong.html -- 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.
I see the problem right there by davidwr · 2012-12-21 08:01 · Score: 3, Funny

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. C:\Users\Programmer1>

--
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Re:Eclipse by gantzm · 2012-12-21 08:02 · Score: 2

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

--

Excessive forking causes un-wanted children.
Re:Eclipse by DickBreath · 2012-12-21 08:02 · Score: 2

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.

--

I'll see your senator, and I'll raise you two judges.
In answer to the last question by cfulton · 2012-12-21 08:05 · Score: 4, Informative

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.
There was a post on /. (12/19) that answered this. by gcnaddict · 2012-12-21 08:07 · Score: 4, Insightful

"How Experienced and Novice Programmers See Code
From one of the links:

I’m excited to see what else Mike’s research uncovers. One aspect he’s interested in is how the approach of inexperienced programmers differs from that of experienced programmers. For example, there seems to be some evidence that following variable naming conventions helps experienced programmers understand the code much quicker, while breaking these conventions leads to a severe penalty. On the other hand, inexperienced programmers seem to take about as long regardless of how the variables are named.
-Eric Holk

--
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
Yes, there are real benefits... by seebs · 2012-12-21 10:26 · Score: 2

It is a heck of a lot easier to read code which is consistent, and it matters much more that it's consistent than which particular standard you use.
Badly-formatted code is much better at hiding errors. If you want a starting point for learning some of what's going on, check out Kahneman's Thinking, Fast and Slow. But long story short:
1. If I see badly-formatted code that ignores coding specs and the like, I generally start with the assumption that whatever I'm chasing down will be in that code.
2. This is nearly always right.

--
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Re:Yes.. by Smallpond · 2012-12-21 10:51 · Score: 2

I usually add a definition of "TLA" just to see who's paying attention.
Re:Standards are (_Not_ Usually) Good (nor bad) by IBitOBear · 2012-12-21 23:22 · Score: 3, 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.

--
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Being A Better Programmer by assertation · 2012-12-22 00:51 · Score: 2

For most of my career I was one of those programmers who clinged to his own particular style of coding. I got away with it because I used an IDE that could rearrange other people's code into my style for me to work on it and then put it back in the other style when I was done.
A few years ago I spent a lot of time studying new stuff on my platform where all the code was written in a style I didn't like and that I had always told myself made things harder to read.
I got over myself as a result.
I think I became a better programmer by reading code written in different styles.
I now think it is the mark of a provincial thinking to cling to your own style at the expense of good relations at your job.