Do You Keep Your Commented Out Pieces?

I think most people can agree that commented code is important in some way or form for most programmers. Where I have personal questions is commented out code. Where do you stand on this? There are some instances when I’m working in other languages and I comment out some debugging stuff so that if I get a hankering later on down the road I can uncomment it and see what’s going on again. Is this a bad practice or do you think it has purpose?

Popular White Paper On This Topic

Hmmm sometimes I may try different things in code - and comment out sections but retain them so I can change back to some path I took earlier. I think this practice is ok during development - but the finalised/complete version of a program doesn't need it - unless it's something totally new to you. And comments make no difference to the executable code produced by compilers. So, as long as you don't confuse yourself (and/or collaborators) I don't see any problems. Another time I might comment out code is that I want to work only on necessary code (i.e. there are maybe niceties - rather than necessities - that can be temporarily commented out until you're ready to add the commented out code before compilation.
Allan

There was a recent thread covering this. I don't think I commented and many people discussed versioning software. The topic has been on my mind lately.

We're a small outfit and don't use versioning. We do keep commented code - it can be quite helpful to see how the where clause of an SQL statement has been changed for example. The history of changes can help to keep from going down the wrong road.

On the other hand many commented changes can be removed over time if deemed not needed. Too many of these comments can clutter the code. You have to strike a balance.

The debugging example you give is a nice one. If I find the debug code useful (especially more than once) I'll keep it for sure.

When you get the bug, you have to make a source change, rebuild, and install the debug version to test for the bug.

What you find is that the code has been changed (members added to structures, function args changed, etc) but all the debug has been left in the old form inside its comments.

So when you uncomment it, you just get a slew of compile-time errors that you have to fix, and you are changing the source you were intending to debug.

If you have debug, it needs to be switchable on and off at run-time. If your project is big enough to need debug code, then it is big enough to have something like a MyAppName.debug file that switches on various named debug groups and levels.

There is code commenting and code commenting. The former where the function is apparent is a waste of time. However, when there are business rules, or the code is sufficiently complex, a narrative and a history of changes is vital. Two years down the road, when the original developer is no longer available, it would be useful to know why the program is structured as it is.
Maintenance history can substantially reduce the time to diagnose what correction is required, if at all.

In this case it is making the best of a bad situation. If you are deciding
to leave dead code behind in a program you should document the reason
somewhere. If you use version control software you can document why code
was removed. If you use "poor man version control", aka commented out code,
you still should document the reason for "deleting" the code, by adding
comment text. You don't know how long it will be before you look at the
code again, or even if it will be you editing the code in the future.
Adding appropriate comment text will save the next person time trying to
figure out why the commented out code is there.

Copyright 1998-2015 Ziff Davis, LLC (Toolbox.com). All rights reserved. All product names are trademarks of their respective companies. Toolbox.com is not
affiliated with or endorsed by any company listed at this site.