With all sorts of code metric analysis, unit tests, code coverage, selenium tests, and automatic deployment scripts, you should think that you got most of it covered. But there are other ways to check you code and one of the best is probably gut feeling and common sense reviewing and reading code.

But just because you find code smells and code that start to fall apart doesn’t mean you have the time or want to break your flow with a big restructuring or even a smaller refactoring. You want to  mark it and later get back to it. So you place some comment there, like a TODO or NEEDS WORK and what happens?

Two weeks later you find the TODO but still don’t have the time to do the job properly or you cannot even remember why you put it there in the first place. And when is there time to take care of this code.

In the current team we try to collect bigger restructuring and refactoring to refactor Friday. We are not allowed to add new features during this day, only clean up and clarify the code. So we try to find the TODOs and comments or even collect some comments on our scrum board but we need more structure and a better way to handle code smells.

So we came up with a few ideas for this. The first part was to add a .NET attribute that we can add to classes and methods that we find need work. The found code smells are now marked with an attribute as follows:

[SmellyCat(LevelOfSmell = "This one reeks", 
    YourCodeSmellsBecause = "It’s unreadable", 
    IFeltTheSmell = "Sniffy")]

The attribute includes a way to add details on why and how bad the smell is to be able to handle it later on and maybe give it priority.

The next step is doing something with all these attributes. A custom task to MS build looks like a good start, this is on it’s way and will produce an output that we can include in our code analysis section in TeamCity, currently it produces an XML file so the next step is to add some XSLT and produce a lovely HTML file to include as artifact in TeamCity. The goal here is to find a good level for this build task and simply fail the build if we have to many code smells in the code. Forcing us to take care of the code smells before it reaches unbearable levels of stench.

// Håkan Reis