Beautiful Testing

Discovering Developer Notes

There is an adage I have heard on more than one occasion from the developers I am working with: The code doesn’t lie. Since the code doesn’t lie, it is a fantastic resource for quality information. Given the size of today’s code bases, it is certainly not efficient to try and read through it all line-by-line, looking for things of interest. Instead, you can create a script that crawls through the code, highlighting things flagged as interesting.

“Interesting” is a rather vague term, and that is intentional because things that are interesting vary from project to project. But here are two things to start your personal list:

TODO (and its variants)

Most modern IDEs have a shortcut to insert TODO as a comment in the code, the idea being that the developer is leaving himself a note to come back later and do whatever he is indicating still needs to be done. Too often, though, the code that needs to be done isn’t done, and it is checked in with the TODO still outstanding. This can lead to a silent accumulation of technical debt and schedule risk.

FIXME (and its variants)

FIXME is much like TODO but is an indication of an identified bug (or bugs) in an area of code. I have seen FIXMEs as simple as “Should have a better variable name” and as complicated as “This is completely broken and needs to be redesigned.”

Both TODO and FIXME are useful constructs, but they need a certain level of visibility in the organization, with corresponding entries in the bug, issue, or ...