[time-nuts] Getting GPIB to work on HP5382B Universal counter

Mike Naruta AA8K aa8k at comcast.net
Wed Oct 14 12:46:05 UTC 2009


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
> 



More information about the time-nuts mailing list