On 1/11/11 10:09 PM, Richard Fateman wrote:
>
>> any technical stuff is fine, which I said before.
>> I was reacting to the dates& authors business.
>> I guess I didn't make that clear.
>>
> Well, the stuff about MCOND expressions is fine;
> ...
> I have mixed feelings about this.
> One of the reasons to have some historical background in the code is
> to provide
> additional clues for why the program is the way it is, and not some
> other plausible
> way.
>
> One possible unfortunate scenario goes like this.
>
> 1. Person X designs a new feature and implements it, and it works to the
> satisfaction of X.
> 2. Person Y uses the code and finds it unsatisfactory, actually fixes
> and generalizes
> it so that it works for both X and Y.
> 3. Person Z uses the program but finds it not quite satisfactory and
> decides to
> "fix" it by replacing it by something equivalent to the simplistic
> version of X, and then adding his own
> features. Why? He doesn't understand Y's code. He just wipes it
> out, and
> so unless Y goes back and tests the code, the new version, X+Z seems
> to be just fine.
> And it is, for almost everyone except Y.
>
> This happens.
Indeed. I've seen such things in happen in production code (!!!!)
I also have mixed feelings. I don't care if names and dates are given,
but I would certainly like explanations about why things are changed for
complicated things. Hopefully tests case have been provided to
exercise the changes so when Z wipes out Y's code, tests suddenly start
failing. Yes, this is hard, but we can at least try to make it better.
>
> Now, all of this can be handled using CVS IF everyone reads all the
> comments
> and understands all the parts. And having comments in the code might
> not prevent it from happening. But certainly the amount of comment is not
> such a burden that extra stuff (if accurate) should be discarded.
>
> I have
> heard arguments that any comments are bad. Code should be
> so clear that comments are not only unnecessary, but hazardous, because
> the program might be changed and then the pre-existing comments would be
> misleading, so better not to have any.
> I disagree with that view :)
I do too.
I once wrote some code where it was clearly commented why it was the way
it was, and even referenced the standard specification. Someone later
on commented out the code because it caused some reference tests to
fail. He clearly never thought that the tests themselves were bad.
The tests were actually bad, and the code that was commented out
actually caused failures in type-approval and field tests, where it
really matters.
Everyone should use good judgment. But I guess that only comes one
way---experience.
Ray