Alex Rivera | Logout

Alternatives to commented out code for historical purposes

Asked 2010-06-04T09:33:41.453
11

Does anyone have a valid alternative for using commented out code checked into the repository for findability reasons?

The reason I ask is because I had a discussion with a fellow developer recently on checking in code that is commented out. My stance is that commented out code should never be checked into our VCS since it is not technically part of the codebase, and thus annoying cruft which does not deserve the bytes it is taking up, so to speak.

His counterpoint was that some of the commented out code he checked in still illustrated some work he would like to fix in the future (in this particular point the commenting out occurred 2 years ago, but that is besides the point). He wanted to keep it in the codebase so he could easily find it, and even though it would not currently compile, it still showed in global lines the correct way to solve it.

In the end he agreed, sort of, that commented out code does not belong. But when we were thinking of possible alternatives to his we came up pretty short.

The only options I could think of were:

  • Wiki: just paste it somewhere on a wiki. Drawback of this is that it will get mixed with other non-code related wiki content which may make it hard to search on it.
  • Index all VCS revisions: This is largely theoretical for me, but are there systems which make a codebase and its entire history searchable?

Does anyone know of/use any alternatives? Both my options sound like more work than it's actually worth, but that may be skewed by my reasoning that commented out code is worthless anyway. I'd hate to have to go the "Hey, if you don't have time to fix it now it's not important enough to stay in the codebase anyway" route (but I will if there are no viable alternatives).

Sorry for the horrible title, I could not come up with a better one

version-control comments codebase
Edit
Report

2 Answers

2

some of the commented out code he checked in still illustrated some work he would like to fix in the future

Then he should open a low-priority ticket in your bugtracker, describing that what he would like to fix, and add the presently commented out code as a comment to that ticket. Now he can assign that ticket to himself and no one else will ever be bothered by it.

Commented out code is like any other comment: if not properly maintained it tends to lose its consistency with the code and thus its usefulness.

answered 2010-06-04T10:14:51.910
1

In my experience, the biggest reason for checking in commented out code is that developers hate typing so much that they would rather keep the unused code handy just in case they ever need to type a similar fragment of code in the future.

Your case is a bit different, but I still say "use it or lose it". If the commented out solution fixes something important, then that would be a good motivation for finishing it. It's easy to spend more time explaining why something isn't quite right and "how we were never given the time to fix it" than it would take to do it.

That last point is based on the assertion that developer time is non-linear, and that getting started on something that you're motivated to do delivers much more value than "X hours booked to project Y" every time.

There are version control systems that are very good at creating and merging branches. Mercurial, git, etc. would all be capable of doing this. Even if you don't use one of these as your main VCS there's nothing to stop your colleague creating a local repository to keep his experiments in.

answered 2010-06-04T09:56:27.780

Your Answer