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

I would not concatenate more than two functions, but otherwise I'd go for:

lRet = Function1()
lRet = lRet AND Function2()
lRet = lRet AND Function3()
lRet = lRet AND Function4()
etc