The standard I used in my department was that when anyone changed code, they commented out the original code and then entered their new code with a date and explanation of the change. That way you have the what and why the previous developer originally thought he was doing and what, when, and why you changed it.
This is also very useful for the times you discover why it was originally done that way and you have to remove your modification. :) Maintaining comments and change history requires self-discipline, but reflect the skill level of the developer. Accuracy and note-taking are certainly something that time-nuts are good at. Respectfully, Mike - AA8K Even COBOL needed comments Heinzmann, Stefan (ALC NetworX GmbH) wrote:
While the general advice is sound, comments are a mixed blessing. The main problem with them is that they're in no way checked for their correctness, as the compiler or interpreter ignores them. Quite often that leads to comment rot: When bugs get fixed and features added, the comments don't get updated and get out of sync with the code. Eventually you get conflicting information from code and comments and have to figure out which one's right. An old programmer's saying is: If code and comment disagree, they're probably both wrong. Comments are important, but even more important in my opinion is to try to write code in a way that is understandable without a comment. Try to say it in code, and put in comments where that fails. Don't try to duplicate what the code says in a comment. Rather, explain the general idea or method. Anyway, just my 0.02€ Cheers Stefan
_______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
