The source management system is the proper home for old versions of source code. If, for some reason, it really seems necessary to explicitly note that an alternative version of the current code once existed, then this can be indicated using indirection.

// Previously, surfaces were stored in a vector, not a list.
// A list is now used to support efficient re-ordering.
// Refer to version 1.22 of this file for the vector implementation.

There is a direct parallel with the change history of a document: at times it may be very useful to review who changed what, when, or to examine side-by-side differences with the previous version of the document, but this is achieved by accessing the document's revision history, not by leaving obsolete wording lying around in strike-through style. The up-to-date version of the document should be up-to-date.

Ideally, then, the dead code can be cut away. To achieve this ideal requires proper use of the source management system. Check-in comments should be of the same standard as any other project documentation – they need to be clear, accurate, and must include relevant cross-references (to bug report numbers, for example). An iterative approach to check-ins works well: i.e. take the code in steps towards its new form, checking in after each step is complete.

We may not be dealing with dead code, though. Perhaps the code represents work in progress – functions which are being written and which do not yet work, but which none-the-less belong in the source code repository. In this case, the code needs to indicate why it has been commented out, as already mentioned. An alternative would be to store the developing code on a branch until it matures.

Similarly, if the commented-out code represents the original content of a third-party file, then an in-line explanation is required to make this evident to anyone inspecting that file. Even in this situation, I would argue the original content should be cut and the source control system used to manage the differences.

Debug output often gets commented-out because it degrades performance or fills up screens. In this case, either the debug code really was a one-off, and should be deleted after use, or it should be carefully integrated into the trace system (the trace system being the module which provides the facility to efficiently filter logged output at run time).