views:

80

answers:

3

I regularly see production code from developers (large companies and individuals) that contains code that has been commented out. Presumably this removes earlier attempts at achieving the functionality that didn't work for some reason.

To my mind, this is messy, but potentially has some benefits e.g. on returning to refactor or extend the code, the developer can see what has been tried previously.

Are there any security or best-practice aspects to this?

+1  A: 

Best practice is to use SCM. If you think the old code is really something people will want to refer to in the future, leave a comment of "// We used to do it another way, which had interesting property X -- see revision 103" rather than leaving whole chunks of code that don't do anything.

Commenting out code has its place, but that place is quickie tests that aren't even worth the time to do a branch.

If the code is worth keeping, it's worth more than being lost in a comment somewhere. If it is not worth keeping, kill it with fire.

Chuck
I like the idea of including a comment referencing a particular revision.
Jonathan Day
@Chuck: What if (1) one is using an embedded-system compiler which doesn't optimize out unused methods, and (2) one has a family of similar functions (e.g. put (signed/unsigned)(byte/word/long)), of which some happen to be used at the moment, and some not. It would seem desirable to have the orthogonal set of functions readily available, even if some are #if'ed out to save ROM space on the target.
supercat
@supercat: If it's in SCM, it's about as available as something #if'd out.
Chuck
A: 

Best practice is that your code shows only the current. You should be using an SCM that deals with code history.

Josh
A: 

Code should be stored in source control.
Comments should be reserved to explain difficult to understand code or the reason for doing something out of the ordinary.

sHr0oMaN