The Code Convention as Rule

I frowned when my colleagues came up with the requirement of using a tab size of three characters in all our C# and JavaScript source code writing. The requirement came about as a compromise between two different preferences -- one, to use a tab size of two, and the other, a tab size of four. The former of which must refer to JavaScript files.

When they came up with this result, my colleagues missed one important point. Conventions already exist, and they exist to be used. Conventions are not meant to be flexible and adapted to the team. I say that with the strongest of convictions; I haven't yet found a reason to stray from Java's coding conventions in all my years of coding Java. Nor did I have to stray from Microsoft's C# code conventions now that I'm back to C#. I did have to fill gaps sometimes, but I didn't have to bend any existing rules.

Whether the decision to compromise on the tab size of our C# source files was driven by a JavaScript indenting preference or not, the point of interest is that one who wishes to embrace coding conventions must use the existing de facto conventions whenever available.

Philosophy aside, there are pragmatic arguments in support of this preference: the generally accepted convention has already produced zillions of C# files with a tab size of four characters. Upon integration into your projects, such source files will render with an indentation foreign to your conventions. Such files should be pervasive in source code attached to compiled external assemblies that your projects will undoubtedly use. (It seems that Visual Studio and the .NET compilers don't do such a good job of linking a compiled assembly to the original source code. I've had to create the NHibernate source code into C:\NHibernate before Visual Studio let me navigate it.)

Yes, some source files will have tabs and will, as a result, appear as having a tab size of three per your Visual Studio settings. But some won't. And, let's admit it, you don't really want to use the tab character for indentation anyway (a post is pending on this topic).

Yes, you may edit these source files in Visual Studio to force a reformatting of the code and thus a tab size of three. But you and I know you don't want to do that, not only because you don't have the time to do it, but also because you don't want the footprint of such changes in your version control system.

Another pragmatic argument takes shape in dynamic teams (who doesn't have them?). When a new member joins your team, chances are she is already acquainted to the de facto coding conventions. To require of her to stray from these rules is an additional, unnecessary effort.

Don't stray from the established conventions.