Configuration Management - History in Code Comments

Question

Let me pose a bit of background information before asking my question:

I recently joined a new software development group that uses Rational tools for configuration management, including a source control and change management system. In addition to these tools, the team has a standard practice of noting any code changes as a comment in the code, such as:

///<history>
   [mt] 3/15/2009  Made abc changes to fix xyz
///</history>

Their official purpose for the commenting standard is that "the comments provide traceability from requirement to code modification".

I am preparing to pose an argument that this practice is unnecessary and redundant; that the team should get rid of this standard immediately.

To wit - the change management system is the place to build traceability from requirement to code modification, and source control can provide detailed history of changes by performing a Diff between versions. When source code is checked in, the corresponding change management ticket is noted. When a CM ticket is resolved, we note which source code files were modified. I believe this provides a sufficient cross-reference for the desired traceability.

I would like to know if anyone disagrees with my argument. Am I missing some benefit of commented source code history that change management and source control systems cannot provide?

Answer 1

For myself, I have always found such comments to be more trouble than they're worth: they can cause merge conflicts, can appear as 'false positives' when you're trying to isolate the diffs between two versions, and may reference code changes that have since been obsoleted by later changes.

It's often (not always, but often) possible to change version-control systems without losing metadata. If you were to move your code to a system that doesn't support this, it would not be hard to write a script to convert the change history into comments before the cutover.

Answer 2

A comment allows you to find all the changes and their reasons in the code right where they are relevant without having to dig into diffs and version control system intricacies. Furthermore, should you decide to change of version control system, the comments will stay.

I worked on a large project with similar practice that had changed of source control system twice. There wasn't a day when I wasn't glad to have these comments.

Is it redundant? Yes. Is it unnecessary? No.