Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ask Slashdot: Do Coding Standards Make a Difference?

Posted by Soulskill on 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?"

31 of 430 comments (clear)

  1. After 42 yrs programming I say... by rs79 · · 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 · · 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 · · 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 Decameron81 · · Score: 5, Interesting

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

      --
      diegoT
    4. Re:After 42 yrs programming I say... by BasilBrush · · Score: 5, Insightful

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

      You didn't understand his first point.

    5. Re:After 42 yrs programming I say... by casings · · 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.

    6. Re:After 42 yrs programming I say... by blackm0k · · 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.

    7. Re:After 42 yrs programming I say... by IAmGarethAdams · · Score: 5, Funny

      (I know, I know, it means you must be a PHP developer)

    8. Re:After 42 yrs programming I say... by Decameron81 · · 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
    9. Re:After 42 yrs programming I say... by UnknownSoldier · · 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.

    10. Re:After 42 yrs programming I say... by luis_a_espinal · · 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.

    11. Re:After 42 yrs programming I say... by VortexCortex · · 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.

    12. Re:After 42 yrs programming I say... by lgw · · 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.
    13. Re:After 42 yrs programming I say... by Fastolfe · · 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.

  2. "a net productivity gain"..YES by who_stole_my_kidneys · · 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 · · 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 · · 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. Yes, they do by Anonymous Coward · · 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 · · 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.

  4. Don't forget the Terms and Acronyms by Smallpond · · 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.

  5. Long story short... by beelsebob · · 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 · · 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 Rakishi · · 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.

  6. It's your responsibility. by pclminion · · 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.

  7. Naming, sure. Whitespace? No. by TheNinjaroach · · 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..
  8. Most Java shops I've worked automate code style by neiras · · 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.

  9. Ya to me sounds like "I'm special" syndrome by Sycraft-fu · · 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 · · 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.
  10. It helps by Cro+Magnon · · 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.
  11. In answer to the last question by cfulton · · 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.
  12. There was a post on /. (12/19) that answered this. by gcnaddict · · 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/