Code metrics tend to draw a lot of opinions from developers on both sides of the fence.
Generally, I’m on the side of monitoring metrics, but not breaking the build because of them. I want to know trends, not encourage people to play a game with the system. In other words, I don’t want to “teach to the test,” I want the test to be an accurate representation of what we’re dealing with.
For example, imagine we’ve turned on the monitoring of tags in the codebase. This will count the number of comments that start with
//FIXME, and other common tags. In a world where we only count these, we’ll see very clearly
- how many tags we have
- the accumulation vs time
- which classes are the worst offenders
With this information, we can adjust our approach to conquering technical debt and strike our team’s ideal balance of fixing and creating.
If we instead attempt to improve the code by capping the number of
//TODO tags in our system, our team will risk ending up with all sorts of undesirable consequences:
- new, valid
//TODOcomments not being added
//TODOs deleted without being fixed
//TODOs turned into much-less-detectable regular comments
- clever wordplay in the form of
- munging changesets by checking in completely unrelated
Each project, team, and metric category can have special circumstances. Given my experience with the list of the negatives for breaking the build on
//TODOs, I’ll strongly consider the necessity of that in the future.