Do you update ancient code comments that are wrong?

Question

G'day,

Inspired by a comment I made in my answer to this question on commenting Perl regexps I was wondering the following.

When you are working on older, old, bloody ancient, code do you update comments that are out of sync with the code or do you just update the code and ignore the comments that are already "miles out" from the reality of the current code?

I guess basically approaching things from the "broken window" syndrome?

BWS basically says that people just say "stuff it" and don't take care to fix errors that are there if they see that people, already involved with the system in question, didn't care enough to fix these sorts of things. A totally pervasive mind set IMHO!

I'd be interested to see what other people "at the coalface" do.

cheers,

Answer 1

I always try to update them if I can, or at the very least add a note to the effect that they might be wrong. It's a worthwhile investment of a small amount of time.

The other thing I always do is add any relevant bug numbers, and what effect those edits had - that's always useful to see further down the line.

Answer 2

If the comment is necessary, I'll update it, otherwise I'll attempt to change the code to the point where I can just outright delete the comment and let the code document itself.

Answer 3

Recently I started following more of Uncle Bob's Clean Code advices and I'm trying to transform comments into functions that enclose (extract) the commented code in a function that is at least as meaningful as the comment it replaces.

Answer 4

I would fix the comments.

Why not fix any problem you can? If you understand the code you're working on, the comments should be the easiest fixes of all. Obviously if you've taken the trouble to delve into it the code should all be left better than you found it.

I would even posit that in groups where multiple people will be touching the code the comments could be considered just as important as the code itself. Without it the communication of ideas is broken down.

In practice I probably don't comment as well as I should. It's hard to admit that you or someone else will probably be digging around in your "masterpiece" later.

Answer 5

If your documentation is being generated from the comments (I highly recommend this anyway) then yes, I keep the comments in meticulous synch with the code.

Answer 6

I will absolutely fix bad comments.

Sometimes it is just to delete them so that they don't mislead.

Better still, I prefer to refactor the code so the comments are not necessary - self documenting code is better than comments because it can't get out of date.

Answer 7

I immediately fix the comments if I see a problem, and probably note down what it would take to improve the code.

If I then get hit by a bus, the code is all the better for my quick, pointed attention.

Then, if I have time, I'll sort the code itself out (fixing it usually requires time consuming regression testing). If not, I'll leave it for another day, but at least I'll know what the problem is right away when I do have time to come back to it.

Answer 8

Comments are oftten really useful for telling any future maintainers or programmers either what the code is doing or why it is doing it that way.

If you change the code without updating the comments, at best it's going to be confusing, if not downright misleading.

Answer 9

I strive to follow the Boy Scout Rule and leave the code cleaner than I found it. I will look to update the comment or refactor the code to obviate the need for the comment. I find that it is generally better not to have a comment at all than it is to have an incorrect comment.

Answer 10

If the project is under version control (and it should be nowadays, but you never know) and there's a huge hunk of out-of-date comments, I delete the hunk and leave a new comment to the effect that I've deleted a hunk of old comments that no longer seemed illuminating, and I submit with a note that I've deleted out-of-date comments.

Eventually, I'll remove the comment that mentions the deletion, or replace it with comments that apply to the new code.

---

However, here's the downside to changing old, supposedly meaningless comments in a system that's being maintained by a group of programmers:

The comments aren't acting as comments anymore! They are acting as landmarks for programmers familiar with the code. They're landmark comments as opposed to explanatory comments.

Programmers may actually be searching on keywords in landmark comments to navigate the file.

If you remove landmark comments, or even change them, you may drastically slow programmers who are using them to navigate the file. You're messing with the mental maps of people who have a long relationship with the code, and you'll do more damage than good. The brain's a funny thing. It may be much easier to remember a word or phrase in a funky comment than the name of a method.

It seems to me that if the comments are dreadfully out-of-date with the code, you should learn why. It seems incredibly presumptive to assume that the other programmers don't care about the code. Maybe they do, maybe they don't. If you're taking over the files from a guy who left, and you have clear ownership, dig in! If you're the new guy amongst a bunch of guys who've been working on the code for 20 years, and there's other evidence that they do care about the code, maybe you're missing something.

This is similar to the question of reformatting--changing spacing, altering where the opening braces go, etc. And much depends on ownership. Are you going to be in a file 20 times as much as the guy next to you? Or 1/20th as often? If it's the latter, do you really want to disorient him?

So make sure that's not what you're doing, or tomorrow you may hear someone yelling, "Where the hell is that function?"

Answer 11

When i find useless GhostDoc-generated comments, i sometimes just delete them:

What's the purpose of these comments?

/// <summary>
/// Saves the form properties.
/// </summary>
/// <param name="form">The form.</param>
/// <param name="propertyNames">The property names.</param>
void SaveFormProperties(Form form, string[] propertyNames);

Answer 12

I don't fix bad comments. I just delete them. (Or replace them with a single dash as comment.) In general, deadlines are close by so I might spend a second to select, then delete a bad comment, but spending 30 seconds or more to rewrite it would be a waste of time. (And a waste of your concentration.) Once the deadline passes by, things become more relaxed again, at which point it's time for a general code review to put back some new comments.

But then again, you'd have to notice the bad comments first. In most cases, such old code files are often used without being reviewed that closely. And they've often already proven to be working so why would I even look at the comments?

Answer 13

I would fix the comments. I saw some answers said they would rewrite the code if the comments were out of date. It seems absurd to me to rewrite working code just because the comments are bad. That kind behavior might even get you fired if your work is important enough.

Answer 14

As a fairly fresh programmer, I don't really work much on older code as much as my own, but I try to go back every once in a while to ensure my own comments are mildly close to the truth. It makes no sense to leave comments that don't properly describe the function of the code.

That said if you're in a hurry it makes no sense to waste too much time updating comments. Adding one to the effect of "This is out of date" solves the problem of retaining navigation without leaving it ambiguous as to how accurate it is.

Answer 15

I always fix the comments - primarily because I am usually the one who works on a piece of code. It may be an OCD like thing for me, but I just like code that I am working on to look nice - good variable names, formatting (not an issue now with modern IDE's), and comments.

I don't believe code can be "refactored to the point it is self-documenting". It can be refactored to the point where only comments for functions, procedures, member variables, classes etc. are needed, because each function call is only 1-5 lines each. Coming from a Lisp background I like to program through decomposition - much simpler, testable, and easier to prove correct.