The next version of BlogEngine.NET is moving closer and closer by the hour. We are closing down features and concentrate on finishing the ones not already done. That got me thinking about delivering quality code and what every project probably would benefit from before a release – a thorough code quality session.

When you are feature complete, what do you need to make the code as close to perfect as possible? Remember, perfect is an illusion and a matter of subjective interpretation, but you get the idea. You need all the steps to ensure that you release a quality project that works perfectly. For an ASP.NET project like BlogEngine.NET, I would suggest these steps.

Test and fix

Work your way through the bugs until you hit a zero bug bounce. Then test again and make sure you didn’t break anything. Do this through all the steps. No matter what test methods you use, make sure to run them all. This one is a no-brainer.

FxCop

Run FxCop on all your code and make the suggested changes to the code. Not all the suggestions are valid, but make sure to know why you don’t apply them. By running FxCop you make sure that your code is up to certain best practices and that helps eliminating errors.

Compiler warnings

A project ready for release shouldn’t have any compiler warnings at all. No exceptions. Often it’s because there is unreachable code or missing comments.

Complex code

This should have been caught in the code reviews long time ago, but there are always the last minute changes to check. Complex code is the root to all evil, so make sure to simplify it right away.

Documentation

Go through every file in your project and look for insufficient comments. When you look at a class or method you should know right away what is going on. If not, then either the code or the comments are insufficient. Rewrite the comments so every developer on the team, even future ones, can pick it up easily.

Coding standards check

There are always places in your project where the coding standards has been ignored or forgotten. It happens. Go through the entire project and make the changes needed. This makes it much easier for others to understand the code.

Deployment

If you’re project requires deployment then make sure to test every possible scenario. For a web project you might want to check if you application can run in medium trust and if your URL rewrite mechanism works in IIS 7.

Release

I probably forgot some steps, but these are the big ones in my book. So how long time should it take to complete these steps you might wonder? Well, it takes till you are finished. When you are finished, go through all the steps again to make sure. Then you release and throw a release party. Don’t drink too much.

Earlier today I did a code maintenance session on BlogEngine.NET using the excellent FxCop tool. It was a while since I’ve did so there were quite a few things to correct in the code. I actually like spending time with FxCop and fixing the broken rules. There’s something very relaxing about it. Even though FxCop is excellent, it is not without its quirks.

Compound words should be cased correctly

Based on this rule, FxCop told me to correct the spelling of Whitespace to WhiteSpace. I didn’t think more about it and just accepted that whitespace probably isn’t one word but two. After the change I ran FxCop again and, lo and behold, it suggested that I should change WhiteSpace back to Whitespace. Hmm, thought I just did the opposite because it broke the rule.

Avoid namespaces with few types

This rule makes sense if you only have a single class in a namespace, but it breaks if you have fewer than 5 types. Now here is the thing. I have a namespace with only four types and I want it that way. Stop telling me that I shouldn’t!

Do not pass literals as localized parameters

This rule is a globalization rule that breaks if you write the content of a string manually in the source files instead of putting them in resource files. When I throw some exceptions or construct some strings that I know will not be localized then I couldn’t care less about this rule. If I were to put every string in a resource file, it would be hard to work with. I turned the rule off.

Do not declare static members on generic types

In English: Don’t write a static method or property that uses Generics in its declaration. The rule also states that you must never exclude that rule no matter what. It states that in order to call that method you need to write bad code such as

someObject.GenericMethod<int>();

Well, that is not correct. You can have a static member using Generics without calling it with the <type> syntax if you know how to write the members correctly. Apparently it doesn’t take smart people into account for this one.

Conclusion

Even though this post sounds a bit negative I’m still a big fan of FxCop. Some of these rules are perfectly fine to break according for some scenarios. The rules state that them selves. These few ones have just annoyed me ever since I started using FxCop a couple of years ago.