Editorial Note: I originally wrote this post for the SubMain blog. You can check out the original here, at their site. While you’re there, have a look at GhostDoc.
Before I get down to the brass tacks of how to do some interesting stuff, I’m going to spin a tale of woe. Well, I might have phrased that a little strongly. Call it a tale of corporate drudgery.
In any case, many years ago I worked briefly in a little department, at a little company that seemed to be a corporate drudgery factory. Oh, the place and people weren’t terrible. But the work consisted of, well, drudgery. We ‘consulted’ in the sense that we cranked out software for other companies, for pay. Our software plumbed the lines of business between client CRMs and ERPs or whatever. We would write the software, then finish the software, then hand the software over, source code and all.
Naturally, commenting our code and compliance with the coding standard attained crucial importance. Why? Well, no practical reason. It was just that clients would see this code. So it needed to look professional. Or something. Didn’t matter what the comments said. Didn’t matter if the standard made sense. Compliance earned you a gold star and a move onto the next project.
As I surveyed the scene surrounding me, I observed a mountain of vacuous comments and dirty, but uniform code.
My Complex Relationship with Code Comments
My brief stay with (and departure from) this organization coincided with my growing awareness of the Software Craftsmanship movement. Even as they copy and pasted their way toward deadlines and wrote comments announcing that while(x < 6) would proceed while x was less than 6, I became interested in the idea of self-documenting code.
Up to that point, I had diligently commented each method, file, and type I encountered. In this regard, I looked out for fellow and future programmers. But after one too many occasions of watching my own comments turn into lies when someone changed the code without changing the comments, I gave up. I stopped commenting my code, focusing entirely on extractions, refactoring, and making my code as legible as possible.
I achieved an equilibrium of sorts. In this fashion, I did less work and stopped seeing my comments become nasty little fibs. But a single, non-subtle flaw remained in this absolutist approach. What about documentation of a public (or internal) API?
Naturally, I tried to apply the craftsmanship-oriented reasoning unilaterally. Just make the public API so discoverable as to render the issue moot. But that never totally satisfied me because I still liked my handy help screens and Intellisense info when consuming others’ code.
And so I came to view XML doc comments on public methods as an exception. These, after all, did not represent “comments.” They came packaged with your deliverables as your product. And I remain comfortable with that take today.