>'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.

Interesting! It also assumes there is no field called tcEmpno at the lParameter line. ;) That's a tough one to debug too!

I've taken to doing a vartype on the parameters and issuing an error if the checks fail.