The Importance of Commenting and Documenting Code?

mrtrumbe asks: "The company I work for is in the process of creating a development standard to be applied to all projects. The topics being considered range from dictating the formatting of the code (an issue on which there is widespread agreement), to creating a standard for commenting and documenting the code (a far more contentious issue). On the issue of commenting and documenting, there are two extreme views being considered with most employees' opinions falling somewhere between them." To comment, or not to comment. And if you do choose to comment, what's the best way to standardize it, company-wide? "The first view is that commenting and documentation will protect the firm from bad programmers or a programmer abruptly leaving, make the code far easier to understand to someone unfamiliar with the codebase, and are necessary for all public, private and test code. The opposing view is that there are more effective ways to mitigate the risk of bad and disappearing programmers (like mandated shared ownership of code and sufficient oversight), that comments are not necessary for clarity and can be dangerous if not kept up to date (which is considered likely), and that documentation is necessary only for public code. Where does Slashdot stand on this issue? Please share any success stories and recommendations for a company-wide standard on commenting and documentation of code.

Comments

Are you serious?

[zhobson]

If your code is not commented it's not complete. My advice is to fire every developer that doesn't think that comments are necessary.

Re:Are you serious?

[Anonymous Brave Guy]

I've read all the other replies to this comment at the time of writing, and it's a fascinating discussion. Initially I thought you were just a troll, given that you claim to have produced completely bug-free projects and never to use comments, but now I think you've just had a little too much of the agile kool-aid, so I'll address some recurring points one by one.

On the trustworthiness of documentation (comments, paper or otherwise): no, you shouldn't absolutely trust them above all else. The final authority about what is happening is always the code. But if your documentation is any good at all, it's not the sort of thing that you refer to last, it's the sort of thing you refer to first. The documentation isn't the implementation, it's just a map of it, telling you what should be happening. Comments are the guidebook, highlighting the major attractions as you reach them and pointing out the subtleties that aren't apparent at first.

The most successful projects I've worked on have relatively little documentation, but it's well-written and useful. My current project, for example, has perhaps 200,000 lines of code. We have maybe 20-30 reference documents, each electronic and running only to a handful of pages, describing the overall design of the major subsystems and broadly speaking how they're intended to interact. The implementation speaks for itself, with explicit comments generally reserved for things like dividing up longer functions into logical sections, citing references that describe how the algorithm works (from our own documentation or otherwise), or clarifying intent on the odd occasion that the code isn't completely self-documenting. Notice that none of these things, except possibly the last, are likely to need amending just because you change the code.

You also seem to be arguing that it is unnecessary to maintain any sort of coherent overall design in an "agile" project, because your automated tests guarantee correctness. Sorry, but I think you're seriously misguided on both counts.

Automated tests are a useful mechanism for increasing reliability, but they're no substitute for a logical design, code review, or any of the other things that contribute to code quality. Unless your tests cover every code path with every conceivable set of inputs, they simply can't do that. My current project has an automated test suite that runs to 1,000s of tests, and yes, they're very useful for spotting major errors and regressions, but they still don't catch anything like all the bugs. No test suite for a large scale application ever has 100% coverage. And even if the test suite does pass in its entirety, it's no guarantee that you got the answer the way you intended and all your code is working. Two wrongs do make a right, if you incorrectly multiplied by -1 twice.

As for the presence or otherwise of an over-arching design, what you say is true: your code and tests are indeed guaranteed to give you the results your tests say you will get for as long as the tests pass. Of course, that doesn't mean that you can easily extend, modify or reuse that code. In fact, my experience of projects developed with the methodology you describe is that they're written very quickly, but rapidly become almost unmaintainable; someone will find a bug that your tests didn't, and you'll dutifully write a new test, and then it will take you a week to refactor this and elevate that until you can get the test to pass without breaking anything else. The guys who had a carefully planned, well-maintained and systematic design would probably have fixed that bug in five minutes, and without breaking anything else, because the problem would have been localised, easy to track down, and unable to adversely affect other areas of the system.

Speaking of code reuse, I notice that you're very keen not to bring context into things. I hate to break this to you, but code without context is meaningless, no matter how "reusable" it may be. When context starts to interfere with your reality, a lot of