Consistency is the principle benefit of having a documented coding style. The details of the style itself are usually not terribly relevant. If you are a developer who works on multiple projects, or even one who just dabbles at home after work, you probably have to cope with at least two different coding styles.

Visual Studio has pretty powerful code reformatting features, but the configuration of those features are scoped to the user, not the solution file. You can export those settings and import the correct ones as you switch projects, but there’s a lot of friction along that path.

One solution is to use an external code reformatter, such as Artistic Style or Uncrustify. The latter is currently my personal favorite (but see below for a warning) due to the huge variety of configuration options it supports. More options certainly means a more tedious initial configuration, but it also means the tool will be adaptable to a broader range of styles. Besides, there are useful tools like the Universal Indent GUI, which provide user-friendly ways to configure a variety of popular code formatters.

Once you have configured Uncrustify, you can check the config file in to an appropriate spot in your repository (you can check in the Uncrustify binary as well, but it’s GPLv2 so be aware of the ramifications); that way all developers will have access to it. The best place for it is probably next to the solution files or in another root-like location within your source tree.

You can then configure your IDE(s) so that their default formatting commands instead use Uncrustify. In Visual Studio, for example, one can set up an external tool. Assuming uncrustify.cfg is next to the solution file, then the command line

-c $(SolutionDir)uncrustify.cfg --no-backup $(ItemPath)"

will reformat the current source file. You can then assign a keyboard mapping (or reassign the one for Edit.FormatDocument, like me) for quick access.

This doesn’t work flawlessly, unfortunately — such a simple external command requires you to make assumptions about where the format configuration is stored, and that assumption may not hold across all your projects if you don’t have the necessary degree of control over them. External commands also require you to tolerate that obnoxious, brief console window pop-up (or redirect the command to the output window, which will steal your keyboard focus). But overall it’s much better than having your fellow developers come and complain that you screwed up the bracing style in ReallyImportantFile.cs yet again.

Note that as of this writing, however, the released binaries of Uncrustify have a bug that prevents them from handling files with BOMs, such as those created by Visual Studio by default. The bug has been fixed, but you will need to build the application from source to get it. This is fortunately relatively painless, but if you don’t have the capability to run “configure” (i.e., you’re on Windows and don’t have it) you won’t have the “uncrustify_version.h” file you’ll need for the VS project to build. You can just rename “uncrustify_version.h.in” and change the #define for UNCRUSTIFY_VERSION to something sane, though — a bit of a crude solution, but it will suffice until the next release.