Whoa! I did NOT intend to write that little epic on naming conventions. What I originally wanted to do is talk a bit about my own thoughts on the subject then slide into a side topic. This post will be about the side topic: white space

White space isn't given enough attention in coding standards. Sure you read about whether to place curly braces on a separate line and spaces around operators and the like but usually the bigger picture is overlooked.

Readability is the ultimate goal of white space, of course. For me, there is also an aesthetic quality to it. When I use white space, it's too make the code “look” good. The consequence of that is that it is more readable. It's kind of hard to explain. I remember when I talked with someone who was my mentor in this regard. I looked at his code and it stood out. It was well laid out and easy to follow individual statements. But more than that, it made me want to write code that looked like it. That, I think, is part of why I still do it. I want someone else to look at it and think that same thing.

So there are some rules involved. Well, “rules” is a little strong. Guidelines is more accurate. Like the numbers you see on those black and white signs on the highway. I'll list them point form then put some sample code afterward.

  • One space before and after operators (+ - * = += *=, etc).
  • One space before and after the opening parenthesis in if, for and foreach constructs.
  • One space before the closing parenthesis in if, for and foreach constructs. Carriage return afterward. Always...
  • ...except if the only thing afterward is a return statement. That's my only exception to the above guideline.
  • One space after the semicolon in a for statement.
  • Curly braces: one per line.
  • Curly braces must appear for all i, for and foreach constructs. Except if the only statement is a return. Then it's recommended but I'm not going to be Draconian about it.
  • Function calls: No space before the opening parenthesis, one space after. Including when there are no parameters.
  • One space after each comma in a function declaration and a function call. No space before.
  • Else statements always go in a line by themselves.
  • No spaces before or after square braces

I'll stop there. That should be enough for you to get the idea. I should also point out that you can configure Visual Studio 2005 to enforce every one of these rules. Here's the sample code I promised:

private void returnSomeValue( int parm1, string parm2 )
{
    // Operators
    int i = 1 + 3;
    i += 1;

    // if, for and foreach
    if ( i == 1 )
    {
        // Do something
    }
    else
    {
        // Do something else
    }

    for ( int j = 0; j < 100; j++ )
    {
        // Loop
    }

    // Exception to the guideline
    if ( i == 100 ) return;

    // Function calls
    string theValue = i.ToString( );
    theValue = String.Format( "The value is {0}", i );

    // Casting
    TextBox textbox = (TextBox)Page.FindControl( "textBox1" );
    string text = ( (TextBox)Page.FindControl( "textBox1" ) ).Text;

    // Square braces
    string[] myArray = theValue.Split( ',' );
    myArray[0] = "moo";
}

The only real funkiness is the second line in the Casting section where you have some parenthesis with spaces and some without. That took some getting used to...

If you want justification for any of these rules, just ask and I can make something up that sounds plausible. The point is that I like how this code looks. And when I see code written like this, it tells me that the author cares about his or her code and more importantly, cares about people who may have to look at it in the future. This author is, say it with me, a Conscientious Coder.