When at work the other day, I had a conversation with a colleague about some of the stuff I was doing outside of work. He was surprised that I was actually more exacting on the code that I do in my spare time than the code at work. It was an interesting conversation as he is what we call a “cowboy coder”. Don’t get me wrong, the industry needs cowboy coders as much as they need a lot of other types of coders.
From my experience, a cowboy coder is someone who gets in there, minimally gets the job done and gets on to the next problem to solve. A positive to this is that they get things fixed quickly. There are a number of bad things though, that need to be mentioned. Usually, a cowboy coder will try and find the minimal set of exit criteria and then aggressively work towards that solution. This means that things such as coding standards and running tools such as CodeStyle and FxCop are not done, or ignored, as they “do not add anything to the code itself”. It is often very difficult to convert a cowboy coder to a coder that believes in spending some extra time on quality, as they perceive quality differently.
Myself, I am of the opposite spectrum, but willing to work on some middle ground. I perceive quality as something that can be qualitatively measured using accepted tools and practices. Exit criteria are not meaningful unless the business owners understand the trade offs involved in each solution. Best practices are followed as much as possible as they are… well… best practices. If a number of people in the industry have put their heads together and decided that something is a best practice, it sounds like a really good idea to follow it unless there is a good reason not to.
Let’s apply this to my Asteroids project. While I could have posted the code up here already, I am running it through some rules and FxCop, some written by me and some written by experts. The ones I wrote are usually codifications of my style or of practices that others have looked at.
The two that usually get me are a high McCabe Cyclomatic Complexity index and a method having too many instructions. The Cyclomatic Complexity, or CC, measures the number of branching points that you have within an object. Hence, a method with a single statement would have a CC of 1, one with a single statement inside of an if or while statement would have a CC of 2, and so on.
According to best practices, the CC for the methods, according to best practices, should not exceed 10(for warning, 20 for error) for a method, and 120 and 240 for a class. If you have something that exceeds these limits, you are writing something that is getting far too complex to test properly. Personally, I think this is a good best practice, as it generates better code that you can have a better handle on how it is tested, so I wrote a rule for FxCop that measures it.
Similarly, the number of instructions is a good indication of complexity of a method. If the number of instructions exceeds 150 for warning or 300 for error, then you have a method that is doing far too much work. At this point, its a best practice to break that method down into two or more methods, refactoring the code to make it more readable, maintainable, and reusable. Once again, this seems like a good best practice to follow, so I wrote another rule.
Now, the stuff I write at home is more prone to experiments than the stuff I write at work, but I still use the same rules plus some extra ones to measure how good my code is. When talking with my friend at work, its an uphill battle. In a number of cases, he has written a method that has a single switch statement with over 30 cases in it. Even he knows it is not very maintainable, but he doesn’t think its bad because he wrote a 25 line documentation block at the top that explains how to make modifications. Sigh.
Well, asteroids v0.9 is close to being “clean”, at which time I will post the code.
