Here I am again with a follow up post in my series on fixing a real world legacy application. I’ve been continuing my work with NDepend and wanted to give an update on what it has helped me do.

Just a small reminder: the application is a web application to make forecasts about the World or European championship football/soccer. You can read more about it in my first post.

Mutable Statics

I had a large class containing all the teams that can be in the tournament. It was full of public static fields that returned a mutable type. This allows you to change the state, which can cause unexpected side-effects for other pieces of code that make certain expectations about this state. This was easily fixed by making the type immutable. While I was at it, I also made the public static fields private.

Documenting Code?

There is an NDepend rule that states that long methods (more than 20 lines of code) should include at least 10% comments. The idea is not to put comments everywhere. If possible, you should refactor the long method to make it more clear. But sometimes, certain weird hacks are necessary. This rule tries to detect such situation and tells you to add an explanation for later developers.

In my case, I refactored the methods. I got to a point where I felt confident about the refactoring, but not confident enough to do more without tests. Did I mention I was severely lacking tests? My project had one (yes, 1) test class containing four (yes, 4) tests.

That’s It For Now!

Such a short post? Yes. I stopped refactoring for now, and decided I needed to invest more time in tests first. Because there’s more to say about that than just the fact that I added tests, I’ll dedicate a separate post to that.