>Hi Gregory
>
>>This is what I use most of the times. One entry, one exit. And easier to debug
>
>Thanks for your idea. But one thing I had forgotten to mention was that there are intemediate processing between these if's
>
>But on second thoughts I guess it will be better programming if the intermediate processing is done in custom methods which return .T. or .F., so in my case if BadNextNo() does requrie any pre-processing to evaluate, it has to be done in BadNextNo().
>
>Please correct me if I am wrong.

hi Bhavbhuti,

Yes, more readable is to put the intermediate processing in methods.
But if only a few lines, I use the code below also

local Success
Success = TRUE

local i, ....

do case
case !m.Success

case !method1(...)
    assert FALSE
    Success = FALSE

otherwise
     for i = 1 to .... / do while <....> and m.Success
        
         do case
         case !m.Success  && not here for a do while
              exit

         case !mathodx()
              assert FALSE
              Success = FALSE

         otherwise
             xxx = xxx + yyy

         endcase

      endfor/enddo
endcase

&& go on if Success
do case
case !m.Success

case !method2()
     assert FALSE
     Success = FALSE

....

endcase

return m.Success