I'd say that by the books, it's always a bad idea, but as we know, real life does not always behave by the books. I'm certain there are circumstances that I have not validated the data types of parameters when I was certain that the ones to determine what was passed in would be developers and their mistake should be caught at design time, otherwise shame on them. If the mistake could ever be left up to user behavior or input, I would feel differently about it though.


>Hi Paul,
>
>Not being a native speaker (of English), I felt a bit unsure about proposing the phrase. Your reaction comes therefore as a nice surprise. Thank you. :)
>
>As for your anecdote: It sounds like the original developer has made too many assumptions about prerequisites. OTOH, in defense of him/her, it may also be the case that the functional design allowed him to program according to those assumptions. If that's the case, who is to blame then? As I see it, Thundering Train Programming is a legitimate technique, at least for parts of an application, if it is based on a functional design that says that certain conditions will always be true.
>
>>Hi Peter,
>> 'Thundering Train Programming', I like it. Not 'I like the technique', but 'I like the name'. Here's one of many examples that comes to mind on an app I used to support. In order to validate the detail records for a given header record, it was assumed that the record pointer was already in the right place, and did a skip -1 until the foreign key in the detail table no longer matched the primary key in the header table. (FYI, I gotta save face, I did not code this. :^) ) The problem occurred when old data was archived, and people accessed the header record whose detail records were the first in the detail table. The skip -1's eventually encountered BOF, and the production system came to a halt & emergency measures had to be taken.
>> That app was actually ripe with examples of this & other bad coding techniques. I guess that made it a GREAT app to get stuck supporting right out of college. I learned a TON! We did not come up with a universally usable name like 'Thundering Train Programming' for it, but we did incorporate the original programmers last name into it. I will not use their name, but it would be equivalent to if I did it saying that "Busbian Logic" was used. :^)
>>
>>
>>>'Thundering Train Programming' is the phrase that came to my mind when trying to characterize a certain way of programming. It is typical for the programmer who is allowed to assume, or assuming, that certain preconditions are always fulfilled according to the functional design and that therefore no checks for those preconditions are required in code. If a precondition is not fulfilled, then the application will simply crash. Such crashes are not the responsibility of the programmer, but of the functional designer.
>>>
>>>Why I named it 'Thundering Train Programming'? The train driver pays attention to a lot of things during the trip, but he won't bother about the rails. He assumes the rails exist all along the route. That assumption allows him to speed up the train and pay attention to other things.
>>>
>>>Here's a piece of Thundering Train coding:

lparameter tcEmpno
>>>local ln
>>>select empname from employees where empno = m.tcEmpno into array laEmpname
>>>for ln = 1 to alen( laEmpname )
>>>   do someroutine with laEmpname[ m.ln ]
>>>next

>>>It contains no checks at all:
>>>- It assumes a chartype parameter is indeed passed.
>>>- The existence of the table is assumed.
>>>- The existence of the field empname is assumed.
>>>- It is also assumed that there actually is at least one record found.
>>>
>>>Is it bad code? Not as I see it. But the programmer should make clear in the documentation why there are no, or only so little, checks.