[Shivetya]

I understand the rule, we have this rule in place with a caveat. The rule protects us from a few common events, first being that where some developers just love to tinker with code outside the scope of their project. The second is simply a bad design where the results affected other code in unexpected ways.

There have been a few times were code was reverted and having the code merely commented out saved time, time spent cut/pasting from archive. Even with a good CMS keeping commented out code can serve another purpose, knowing what was when and why. That way we can avoid the "well back in year X we had a rule" because we have the code readily accessible.

For large blocks (subroutines/procedures/etc) it is not uncommon to move the whole to the end of the source.

[glennsayers]

"saved time, time spent cut/pasting from archive"

Surely source control would be a nicer way than copy/pasting old code back in?

[wladimir]

I've seen this mostly as workaround for broken source control systems, along with a change log at the top of each file. For example with ClearCase it can be a hell to find out preceding revisions of a file (the tools are slow and very user unfriendly), actions that are trivial with more modern systems.

I tend to agree more with coding guidelines that go exactly the other way: Do not leave around any commented out or dead code. It breaks the flow of reading the code and can cause confusion as to what is actually happening. If you need to refer to an old state of the code, just provide a commit id in your comment.

[bruceboughton]

>> Even with a good CMS keeping commented out code can serve another purpose [..]

This, here, is your problem.

[alexchamberlain]

What is wrong with developers tinkering with code outside the scope of their project?