>>'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.
>
>Yes, the fourth assumption is extremely dangerous:

A missing rail is also extremely dangerous. Nevertheless, the train driver does not pay attention to that possibility (possibility?). What if there will always be a record according to the specs?