>[snip]
>>>Why would a customer sue the programmer/company if the code correctly follows the specs and the specs have been approved in advance by the customer? You are over-cautious, too frightened, and probably because of this structurally spending more time on a product than is paid for. One note here: I'm not saying that I do not, did not, make the same 'mistake'. This whole discussion is also self-reflection and self-criticism, that is, I'm also challenging some of the presumptions I have made myself all past years.
>>>
>>
>>Isn't spending time thinking through all of these issues as we write a module taking more time than just following one's habitual stlye?
>>
>>I think I understand that you're trying to examine the pros/cons of TTP. I'd like to see this put on the wikipedia for an even broader discussion. I'm not trying to say you're wrong or right. This is a good discussion.
>
>You understand well. I like the UT esp. because of the quality of the feedback here. I'm not saying that all feedback is positive, but it's generally better than in the newsgroups.
>I assume you are not refering to the real wikipedia, but to the foxwiki from Steven Black? Why do you think that there will be a broader discussion there? Is that your experience?
>

No. I was thinking of wikipedia. There are discussions of computer technical issues.

>
>[snip]
>>>
>>>When I see code where all variables have mdots, even when they get a value assigned, I will not think lowly of the original programmer. Rather, I'll think "hey, here we have one more programmer who sides with Mike Yearwoord!". No problem. However, you yourself gave a striking example of where it can lead to. Your knowledge of the parameters command contained a flaw, since you didn't know that the parameters can not be something else than variables. But it's only a minor flaw, I have to admit.
>>
>>You did mention the psychology of programming. My memory of the working of mdots regarding lparameters was wrong, even though I wrote the original entry for that very thing in the wiki and despite how strongly I feel about mdot. Just goes to prove human error is too great a problem to dismiss. Simple rules are easiest to remember. Simple habits are easy to form. Despite the specs and the internal documentation of a method a programmer calling that method not only can but probably will make mistakes. It even happens to the best of us.
>
>Can't really disagree here.