I hate this. People who do this are trying to keep version management in the file. It is usually a cop-out by people who don't use proper source code control. Change comments belong in the code repository and in a change log or the ticket system, not splashed all through the code itself.
I have had to use files that had this form of commenting. It is useful for one or two most recent changes, if the programmer hasn't bothered to make a check-in comment. Any more than that and it just adds confusion. Modification headers are nuisances, although I can ignore them more easily.
After several years, several programmers, and several dozen changes, I have seen files with more commented-out code than working code, and it becomes very difficult to decipher. I donââ¬â¢t need to see that "aj commented out 03 may 2001" followed by a hundred commented-out lines (or worse, ten lines commented-out followed by ten uncommented, then ten commented-out and so on). Nor am I helped by knowing that "jw changed this nov 99" and "abc added for SR 1234". I need to see what the code is doing now, not what got changed four years and twenty versions ago.
You donââ¬â¢t see circuit boards with all the old traces still there, crossed out, with the designer's autograph. And we donââ¬â¢t need to see the life history of a file in the file itself. The files that are in a directory are not the code repository; they are one version of the code, not a historical document describing the entire history of the project. If you need to see what changed, go to the repository and do a diff, and the check-in comment should tell you why it was changed.
Rog
