>>
>>But why bother to document the lack of the check? If it's in the specs as you say, there's no need. Humbug! The specs are made by humans, the code is made by humans. The checks should be there to protect us from ourselves. To err is human to forgive devine and your boss/customer is no god. They will sue you or your company - possibly forcing you out of a job - at the drop of a hat. The functional specifications do not state that society has become particularly fond of lawsuits. The specifications never mentioned Y2K issues and look at what that caused.
>
>If it's in the specs as you say, there's no need to document things in the code? That would be humbug? So, your code has no documentation that can also be found in the specs? Well, in that case there's also no need indeed to document the no-check, because a next developer will probably indeed read the code with the printed specs in sight on the desk. But many others do place comments in the code that are derived from, or a technical 'translation' from, the specs. I was refering to those developers when I advised that adding a comment why a possible check is not done would be helpful.
>
>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.

>>I do like that you want to call it thundering train because it is like an out of control train. Professional should be following good, safe practices. Thundering train programming is possibly OK to do in some cases, but it it increases the margin for human error multiplied by the speed of the computer multiplied by the number of inter-related subsystems.
>
>[snip]
>>>But I do not support the idea that the mdot should also be used when assigning a value to the variable. That definition is too simple for me (and many others here). We have discussed that several times here in the past, as you know.
>>
>>I understand. However, since you're basically arguing that there's no harm in thundering train programming under certain circumstances, would you be so kind as to recognize that there is no harm - under any circumstances - in my using mdot everywhere I can. There may also be a benefit in that I don't have to try to remember when to do it and when not to. It's an easier habit to just do it everywhere.
>
>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.