Programmers like to argue about a lot of things: the best programming language, the best editor, the best operating system, the best way to format their code, and a whole host of other highly emotional topics that they discuss with fundamentalist religious zeal. It's pointless, and nobody is ever converted, but we programmers seem to get some satisfaction from it anyway. It's odd, in a way, to see a group of people who deal with logic on a daily basis acting so illogical, but there it is.

A favorite topic of debate is coding standards: how variables should be named, comment blocks structured, code indented, etc. Almost every programmer agrees that there should be standards, but won't like whatever standard is imposed. Naming conventions usually are accepted with a few mumbled curses, but an imposed code formatting standard is met with stiff resistance. In my experience, that resistance is especially strong among programmers who work in C-derivative languages: C, C++, Java, Python, PHP, and C#. Just deciding whether the opening brace should go on the same line (K&R Style) or the next line can take an entire morning.

There are some who will argue that imposing a code formatting standard is a needless intrusion and stifles creativity for no appreciable gain. Research is inconclusive, but it tends to support the use of formatting standards, especially in large projects. Having a single code formatting standard makes the code more readable by every team member, making it easier to spot potential trouble areas and tricky constructions. Projects that adhere to a code formatting standard typically have higher quality code — fewer bugs.

If you accept that and decide to impose a formatting standard on your project, you're then left with the problem of enforcing it. The traditional way is through code reviews or spot checks. If you find a module that is not formatted correctly, the programmer who wrote it is instructed to fix the formatting. That increases the risk of errors creeping into the code during the reformatting process. It's terribly boring work, and takes the programmer away from his primary task. As a result, poorly formatted code often stays that way.

"Pretty printer" programs, some quite good, have existed for years. Many development shops have used such tools to good effect, but their use is not commonplace because they are usually external to the development environment and typically require modification to make them format code exactly as desired.

Visual Studio .NET 2002 includes an editor feature that formats C# code using the suggested Microsoft coding standard. Simply highlight the code block in the editor, and select Edit->Advanced->Format Selection (or press Ctrl+K, Ctrl+F), and the code is reformatted. You can do the same thing by deleting and then inserting a closing brace; everything in the enclosing block is reformatted. It's simple and effective, but it's not very flexible.

Visual Studio .NET 2005 maintains the code formatting capabilities of the previous version, and adds a whole slew of new options. Whereas Visual Studio .NET 2002 had only four code formatting options, the new version has five dialog pages of options that give you very fine-grained control over the appearance of your code. Figure 1 shows the general formatting options dialog from Visual C# 2005 Express Edition.

Finally, the Wrapping options let you control whether single-line constructs are left as-is or formatted in the same way as other code. The two options are "Leave block on single line," and "Leave statements and member declarations on the same line." You can view these as exceptions to the rule. For example, a common C# construct to write a read-only property on a single line, like this:

public int Age { get { return age; } }

That's a violation of most code formatting rules, but something that's commonly done to reduce vertical white space in a program. If you turn off the "Leave block on single line" option, then the code is reformatted to look like this:

public int Age
{
    get
    {
        return age;
    }
}

Note that this option only applies if the construct was written on a single line to start with. Enabling the option does not collapse a multi-line property declaration into a single line.

My only real gripe with the interface is that the code samples in the bottom dialog pane only show the effect of the single option that's being changed. That was confusing at first, when I disabled the block indentation option and then changed the case indentation option, the code sample indented the block. I understand why that's done — to show the effect of the change in isolation — but it was a bit disconcerting. It would be nice to see a dialog option that let the user include the effects of the other options settings in the displayed code sample.

The default formatting option settings reflect the suggested formatting that is found in all of the Microsoft supplied code examples and that has become something of a de facto standard for C# code in most shops. I played briefly with some of the options to see that they work, and didn't notice any formatting bugs. The code appeared to be formatted exactly as expected given the parameters selected.

Visual Studio .NET 2005 also cleans up a few formatting oddities that from earlier versions. The most annoying of those, to me, was the automatic formatting of array initializers. In Visual Studio .NET 2002, automatic indentation produced the following when I typed an array initializer:

public string[] test = new string[] {"one",
                                        "two",
                                        "three",
                                        "four",
                                        "five"};

I always found that incredibly stupid. Visual Studio .NET 2005 fixes that by indenting the following lines just one tab level, just like a method declaration or method call that has a single parameter per line:

public string[] test = new string[] {"one",
    "two",
    "three",
    "four",
    "five"};

What I don't understand is why reformatting the code doesn't place the opening and closing braces on lines by themselves, as one would expect:

public string[] test = new string[]
{
    "one",
    "two",
    "three",
    "four",
    "five"
};

Even with that and a few other minor oddities, I've found the automatic code formatting in Visual Studio .NET 2005 to be more complete and flexible than any other code formatting tool I've ever used. Combined with the ability to save and restore options, this feature should almost completely eliminate the need to format code by hand in order to meet imposed standards.

It won't, however, stop programmers from arguing about The One True Way.