Today, I’m going to be talking about coding standards. For those that read the title, this may be unsurprising, given the title “Coding Standards”. What prompts this post? Well, primarily, the Code analysis tool of Visual Studio 2012. I wouldn’t normally run it myself but for some reason it shows up as the first item in the Build menu on my configuration (I’ve since changed it) so I always use it instead of “Build solution”.

Now, The code analysis tool is, apparently, designed for… well, analyzing code. Specifically, it seems similar in concept to some of the features of fxCop. One of it’s “suggestions” was that I declare event handlers correctly. Excuse me? It works, it’s declared correctly. Of course, the “Standard” is to always use a delegate that takes some sort of object (sender) and an EventArgs or EventArgs derived class type as the second parameter. Some of my events were instead declared with, well, my own delegate types. Apparently- according to the code analysis tool, this “isn’t allowed”.

Now, to be fair, I can see where this particular standard comes from. If every event handler can be condensed to void paramobject(Object sender,EventArgs e), then you can simply use a method with that signature for every event handler. This can be particularly useful for mocking tools and unit testing, which can hook every event using reflection to a single event, and then record when they are invoked. But, in my experience, that simply doesn’t happen. Additionally, and particularly true with the inclusion of more recent features such as Expression trees, is the fact that you could feasibly create a lambda variable that meets any contorted delegate definition using reflection- this has the additional advantage of those delegates possibly passing more information.

However, my main problem here is that it doesn’t say why it is a good practice- it just says “I’m doing it wrong” essentially. That is, what I’m doing is a “bad practice” but it never explains why. Which sort of meets with my opinion on “best practices” in that they are often followed but never questioned, sort of like a cargo cult. Most best practices and standards have reasons to exist, but so many people follow them without actually understanding why, so what ends up happening is they apply design patterns, coding standards, and so forth without regard for whether they actually help form a cohesive software framework, and they don’t realize that for every standard or design pattern there are exceptions. Some standards are for readability, and others are intended for maximum maintenance throughput (and of course those two have some overlap). However In my opinion Design patterns, Coding standards, and “best practices” are merely a shield that developers and development managers hide behind when things go wrong. This sort of branches off of one of Paul Graham’s essay’s on the subject, where he talks about how “pointy-haired bosses” will follow industry best practices because if they fail, it’s not their fault, since they followed a “best practice”. However good software development should not rely on blame-shifting mechanics or the use of office politics, but it should be for a single goal: to create a good product. Some design patterns help in this regard, and others hinder. And sometimes certain personality types simply conflict with design patterns or certain coding standards.

One ubiquitious example of this can be seen in many of the languages that use a C syntax. For example, Java and C# take different approaches to naming standards. A java method might be called “setIndex” wheras a C# version might be called SetIndex(). Java coding standards dictate that block structures should use a brace at the end of the line starting the structure, rather than on a new line, as C# does. Now one can understand the purpose of these sorts of standards, which is to make it so everybody writes code in much the same style. However, I’ve never really liked language-dictated coding standards like this. If it was really that important, it would be enforced at a language level, much like Python. The one exception could be argued for public-facing classes, methods, fields, and other members, who should ideally constrain to some standard to avoid too much confusion by prospective client code.