Coding Standards - The Devil Is In The Details

A couple of years back, I was tasked with compiling C# coding standards for our development department.  To be honest, I wasn’t all that excited about the assignment.  Previous attempts had been met with quite a bit of resistance and worthless debate and I wasn’t sure I really wanted to open that can of worms again.  After all, I felt that we had built a talented team of developers who saw eye-to-eye on most “technical things” so why bother getting everyone riled up? As you know, there are many legitimate reasons for “getting everyone riled up.”  In our case, there were two very good reasons which made my assignment somewhat mandatory:

1. We had plans to greatly expand the size of our group in the very near future and documented standards would help get the newbies up-to-speed quickly.
2. Our group’s technical roadmap was becoming more defined (heck, it was taking a turn with SOA) and there were embracing a number of technical advances such as .NET 2.0, Remoting and AJAX and we needed to ensure the existing staff on the same page. 

Ultimately, I accepted the challenge and standards were put in place with very little blood shed.  Of course, I took a few measure to ensure that mud-slinging and stone-throwing was kept to a minimum.First, I anticipated the pain and I didn’t let it happen. To accomplish this, I guess I was a bit evasive.  I didn’t solicit any help or opinions at first.  I did endless online searches and I consulted a few books, but I avoided internal roundtable discussions. I also decided to wait until the documentation was rather polished before requesting any feedback. Once I did seek feedback, I kept participant counts low.  In fact, only a handful of our technical leaders were invited to the review before distributing before the document was distributed to the entire development group.

Second, it was established early on that there would be difference of opinion and this was okay.  Actually, it was almost encouraged, but we all (non-verbally) agreed to keep our egos out of the debate.  This ultimately lead to us coming to a common ground or simply opting to “choose our battles” and accept that we wouldn’t always get what we wanted.  This, in conjunction with everyone knowing their feedback was valued and respected, kept our conversations on track.  Also if a topic got at all heated, we quickly moved onto something else in an effort to stay focused, to keep moving forward and keep everyone happy.

Most importantly, however, we didn’t sweat the small stuff.  If you have been responsible for documenting agreed upon standards, you know what I’m talking about.  Developers tend to spend just as much time hashing out the small stuff as they do the big stuff.  When it comes to establishing your team’s coding guidelines, the devil is in the details.  The classic example is code formatting.  “Which case are we going to use? Camel or Pascal or both?”  “Is Hungarian notation really dead because there is still a lot of merit in using it for form elements?” “Should we prefix private property names with underscores?” “We will use curly braces within our if-else statements even if the conditions are only a single line, right?” “How many spaces are we going to agree to indent?  Please assure me that no one indents using spaces!  Everyone better be using the Tab key!”  There are about a million distracting, time-consuming, worthless arguments which one can have about code formatting (and other similar topics) but they provide little value. These debates can suck the life out of an initiative so beware.

I think I got lucky on my third point. To some extend, our development focus had been rapidly changing over the past few years and the individuals helping to define our standards were now interested in the big picture.  Perhaps we felt we had “better things” to discuss or maybe we had all learned from our past and we knew the danger of  “the details.”  In any case, we concentrate on the big ticket items like namespacing, data access and logging.  We traded in the time we would have given to meaningless debates and we put frameworks and templates in place.    

Whatever your reason, it is important to have standards.  Do yourself a favor.  When it comes time to defining your own, avoid the details.  Otherwise, prepare for a battle which nobody wins and nothing gets done.