Share via


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.

Comments

  • Anonymous
    February 19, 2008
    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.

  • Anonymous
    February 19, 2008
    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.

  • Anonymous
    February 19, 2008
    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.

  • Anonymous
    February 19, 2008
    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.

  • Anonymous
    February 19, 2008
    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. :)

  • Anonymous
    February 19, 2008
    The comment has been removed

  • Anonymous
    February 19, 2008
    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.

  • Anonymous
    February 20, 2008
    The comment has been removed

  • Anonymous
    February 21, 2008
    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.

  • Anonymous
    February 22, 2008
    The comment has been removed

  • Anonymous
    February 26, 2008
    The comment has been removed