I worked in several places that did not use the original control. They seemed to be used to commenting on the code that they changed, explaining the changes so that things could be returned.
I found this to make the code very difficult to read, and it was pretty adamant that such comments were not needed after introducing source control, as the change history would allow you to match tickets to changes.
However, now I'm not sure, I think it might be good to document the main changes to the file in both the file and the commit messages. This should make the code more readable. Do people have a best practice method for documenting code changes so that it is not too dry, but still explains, is someone trying to read it?
Just to be clear, I'm not talking about the list of changes in the file header (which is a whole other argument), but the comments in the code.
source
share