Tuesday, February 19, 2008

Is There Value In Code Uniformity?

There seem to be two opposing views of coding standards.  Some think that they should enforce uniformity in code.  Everyone should use K&R braces, leave two lines between functions, and have a space after the if and before the opening parenthesis.  Others (like me) think that there is little value in uniform-looking code.  The value of coding standards is in their ability to stop bugs from getting into the code.  Patterns that are error-prone, like failing to create a new scope { } for the result of an if statement, should be banned.  Others that are odd but not necessarily error-prone should not.  I'm interested in hearing from you, my readers, on your experience here.  Is there more value in having uniform code than I give it credit for?  Does it really make reading code that much easier?  Do bugs really stand out more or is it just format deviation that stands out?


2/20 - Ugh, my spam filter stopped every response to this.  Unblocked now.


  1. Some general best practices must be upheld to remove gross productivity inhibitors - this is obvious.  
    However, I am always of the belief that the way someone cuts code is just as unique as the way they articulate words or draw a picture.  If we place standards (which in the big picture really means nothing) we are treading on their productivity and their personal opinions about what they are producing...and nobody wants an half-speed unhappy developer.

  2. Well, it is easier to read and to edit.
    Easier to read, because you are trained on a certain style, and you know what to expect.
    Easier to edit, because for instance if you are used to tabs for indentation, using spaces breaks your keyboard habits.
    On the other hand, learning how to focus on the code, leaving behind preconceptions, well, this is actually a real value.

  3. I guess it all comes down to productivity vs. maintainability.
    Enforcing a coding standard (esp one that's rigid) will incur a productivity tax - imagine that the FxCop complains about 100 lines in your codes because it doesn't conform to the standard!
    However, it's easier for OTHER people to catch your bug if  both of your agree on some coding standard, since most of the time you are debugging someone else's bug.
    The balance is to have a standard flexible enough that it doesn't harm productivity (your dev aren't spending hours just trying to fix the code) but be reasonable so that a Code Review / Pair-programming can be done at ease.

  4. I do think it is important to have consistent formatting, because it makes it easier to focus on what the code does, rather than having to decode code meaning from jubled formatting.
    For example, everyone knows that horizontal indenting is a visual cue to compound statements.  So if you look at code that has, within a particular function, inconsistent indenting, it will be very confusing.
    I personally believe that code reformatting filters should be integrated into the version control check-in/check-out processes.  On check-in, the code should be reformatted into the corporate standard format.  On check-out, the code can optionally be reformatted into the dev's or development team's standard format.  That helps make the formatting problem go away without having to define and enforce coding style standards - or worse yet, forcing devs to waste time manually reformatting code.
    In my 15+ years of professional development, I don't think I've personally ever encountered a bug directly attributable to code formatting.  Maybe I've just been lucky, but I personally believe that the main benefit of code formatting is making code easier to understand.

  5. I've experimented with this concept for a while on various projects.  I do tend to find that uniform style, at least within a single file's scope, tends to make the code a lot easier to read.  In the end it frees up mental cycles.  It's not necessarily going to prevent any bugs, but it will save me 30 seconds scanning your function.
    Plus it gives one that "warm and fuzzy" feeling. :)

  6. Code is for people.  The computer doesn't care if the layout is pretty.
    Readability is for the next guy to see your code (it could be you a year from now when you don't remember why you did what now looks idiotic).  The easier it is to read, the easier it will be to understand and to find that bug you've been assigned.
    The problem with coding standards is that mostly they go ignored.  I like to use the m_ wart for member variables, but I don't go around making everybody do it (they do it because it's right!).
    What helps for readability is whitespace, which is my main objection to putting curly braces on the same line with a statement, for one thing.  Really, there is no reason to be stingy with whitespace and it makes the code much easier on the eyes.
    Clearly named classes and variables is also useful.  I sometimes am at a loss for a good class name and get drawn in to the XxxxxManager quagmire.  Mostly, don't do that -- be more inventive that I am.  And for Pete's sake, stop naming local variables "temp"!

  7. I think the brain does get distracted when one reads code that is formatted differently. It takes a strong will not to format it 'properly' before even beginning to understand its meaning :).
    Even worse is when the code is modified by different devs, each leaving his own stamp on the code. For such times, I think if the existing 1000 lines are formatted differently, you should respect that and keep the structure.
    Overall, I believe that 'Form liberates' and this can be taken as a good oppurtunity to mould young devs who have not formed their own style.

  8. "it's easier for OTHER people to catch your bug if  both of your agree on some coding standard, since most of the time you are debugging someone else's bug"  Is that true?  Do they catch bugs easier or just deviations from the standard?
    Many of you talk about readability.  I get that.  If someone's code is really dense or has dozens of blank lines in it (don't laugh--I've seen it), that can be distracting.  If someone doesn't indent properly, that can make reading the code very hard.  
    How far do we go though?  I've seen coding standards that complain if you don't put a space after an if statement.
       if (0 == foo)
    really easier to read than
       if(0 == foo)
    Clearly there are gross problems that can make code hard to read.  Rarely, however, do I see coding standards and enforcement committees stop at the gross problems.  Uniformity often becomes an end unto to itself.

  9. I tend to think that any purely cosmetic layout standards should be enforced by a lint program (or sufficiently intelligent editor), or not at all.  Most coders already have their own natural style that comes out when they're writing, and that's how they're most productive.  Coding is difficult, at least partially because it requires the ability to keep a lot of things in your brain at a time, such as language syntax, variables, functions, side-effects, error handling, etc.  Forcing a coder to also think about where to put their curly braces or how much whitespace to put where is just further straining this juggling act.  Inevitably, something gets paged out, like whether that global variable is in-scope, and this lowers productivity.
    To the people who think that a uniform standard must be enforced in order for code to be readable, I feel sorry for you the first time you enter the real world of maintenance programming.  The ability to read code independent of style is a technique that needs to be in every professional programmer's toolbox.  If you spend any significant time in this game, you will find yourself in the position of having to maintain someone else's code with a different style than yours, and for that, productivity in reading and understanding is even more important than writing.

  10. >Is
    >   if (0 == foo)
    >really easier to read than
    >   if(0 == foo)
    I think so, yes.
    I think this is easier to read than both:
      if ( 0 == foo )
    But any developer worth their salt should be able to handle updating a codebase that uses any of the three... and without succumbing to the temptation to switch to their personal favorite.

  11. I think there is a happy medium. Having wildly different styles makes code harder to maintain and use and hence results in a productivity tax - e.g. if every function used a different naming convention then I end up searhing for the right name each time I want to call the correct convention ... it can even make automatic completion less of a bonus if it is hard to guess the first few characters.
    On the other hand, having everybody rigidly employ a coding standard for every character of code that they write is also a productivity tax ... I've seen too many projects where weeks (yes weeks) are spent purely on making sure that the code conforms exactly to a standard and updating it so that it does.
    In one project in particular, we employed a tool to automate the checking against the standards. Unfortunately the coding standards document was rathr long and the effort taken to set up the tool, and then fix every nit that the tool reported was huge!