Hacker News Reader

Comment by steyh | Hacker News Reader

Why would you leave old code commented out when you can easily look at earlier versions of code with you source code manager?

View on HN

It's true that it will be accessible from the repository, but a few years from deletion, people will forget it is there.

I think that they should've put this right there in the comment, really.

If the comment says where to find it in the repository, when you change repositories you have to remember to change the comment. If enough time has passed since you changed repositories, that becomes a problem.

Emacs is an old codebase. It predates modern repositories, or close to it, and it certainly predates the repository it currently uses.

You don't need to update the comment. You just need to make sure that when you change repositories you preserve the mapping of old commit IDs to new commit IDs. git-svn does this by including the SVN revision in the git commit message.

Ahh, but does git-svn-cvs-rcs do this? It's worth remembering that there were still 15 years to go from when this code was commented out to when SVN was invented.

And for that matter, does burguggle-git-svn keep SVN revisions traceable? Or are we assuming git is the pinnacle of software revision control and emacs would never ever change again.

The comment itself addresses that: it says people will forget that it exists.

The GP's point still stands. Just because the comment offers an explanation doesn't mean it's right.

I feel like there is a big difference between "right" and practical. The world isn't black and white, the authors clearly have had problems when the comment was removed, so it's probably better to just keep it there.

I personally hate when commented out code are checked in to source, but put in a situation where the "right" thing increases the likelihood human error, I'll pick the "wrong" way every time.

How about a smaller comment that says something like:

    /* Here's the deal...Check out what this used to
    look like at http://example.com. */

Except in this case, when the comment was written http hadn't been invented yet :)

That just makes it easier to skip reading.

We have a winner of this discussion!

Putting this into context, in the 1980s and 1990s, though source version control existed, most source was downloaded via FTP and built directly, these source files didn't necessarily contain historic revision information, so keeping the commented line there passes along the context when version control is not present.

Per the article, the comment wasn't added until 2001.

Not exactly.

Per the article, the comment in the comment was added in 2001 when the comment was recreated after someone else deleted it.

The original commented out version predates the first public release back in the mid-80s.

That's the comment saying why not to remove the commented-out code. The commented-out code itself was presumably there in 1985.

From the linked article:

    Don't remove this code: it's true that it will be accessible from the repository, but a few years from deletion, people will forget it is there.

Eh, I've seen some pretty long and ugly commit histories. Finding the useful snapshot in there might be tricky on a very old project, plus the added problem of not knowing to look for it (how would you know which old version was the "simple, good" old version?).

Usually leaving commented-out code in source control is bad, but in this case it's good.

Because you can more easily look at it by pressing M-v/C-v a couple of times. Anyway, in this case, it isn't earlier versions: it's one specific earlier version.

From the way people carry on when they see commented-out code like this, you'd get the impression that people actually paid attention to what was in comments! But if only that were so...

I do. On the particular codebase I'm working on, the code commenting is ridiculous and distracts me from the actual code and comments.

Reply on news.ycombinator.com