>>I agree about the advantage given by name sequencing when refactoring. For a work in progress, it looks pretty clever to me. The only downside is that, after the break-up, the sequence of steps has to be enforced by the programmer, whereas before, it was enforced by the program itself. As an example in the code sample, stp2sub40 is invoked before stp2sub10, which apparently breaks the sequence imposed by the naming convention.
>>
>>IMHO, code like that is a nightmare to debug. I hate code like this:
>>
>>

>>IF ThisFunction() or ThatFunction or TheOtherFunction()
>> .
>> .
>> .
>>

>>
>>Much easier to debug if written like this:
>>
>>

>>llRetVal = ThisFunction()
>>IF llRetVal
>>  llRetVal = ThatFunction()
>>ENDIF 
>>IF llRetVal
>>  llRetVal = OtherFunction()
>>ENDIF 
>>

>>
>>At least if there is a bug in the code you can easily determine which one of the functions is causing the problem.
>>
>>Just my 2 cents...
>
>I agree with you, for an execution controller would be easier to debug like you show, even though I do not have that as a rule, myself. I may use IF This() AND That() AND TheOther() sometimes, when the functions involved in the statement take care of logging their own progress/result. Also, the code in his sample is pretty clear and not that difficult to re-factor into something like yours.
>However, my comment to Thomas was about the naming convention, which may give the false impression that something is executed in a certain sequence. Similar in concept to the critique to the hungarian notation for variable names in foxpro.
>.


My point is, though, that any program that insists on function returns from 20+ functions all cryptically named, is bad in design to start with... No code we write should have all those dependencies..