Hi Cetin,

I'm sorry, I don't agree with your assertion ** IN THIS INSTANCE **.

While your code is readable and operates flawlessly, and I would NEVER assert that this was "bad" or "incorrect" code, I would structure it as follows:

Procedure someproc
*-- Evan would replace
* Local ...
*-- with
Local luReturnValue, ...
With This
  If !.GetValidDateRanges()
    *-- Evan would replace
    * Return .F.
    *-- with
    luReturnValue = .F.
  Endif
  * Some other code ...
  Select ... From ...Into Array .arrItems
  If Type('.arrItems[1,1]')#'N'
    *-- Evan would replace
    * Return .F.  && No items
    *-- with
    luReturnValue = .F.
  Endif
  For ix=1 To Alen(.arrItems,1)
    If .arrItems[ix,2] = 'somecondition'
      *-- Evan would replace
      * Return .SomeOtherProc(ix)
      *-- with
      luReturnValue = .SomeOtherProc(ix)
    Endif
    If .arrItems[ix,3] = 'somecondition2'
      *-- Evan would replace
      * Return .SomeOtherProc2(ix)
      *-- with
      luReturnValue = .SomeOtherProc2(ix)
    Endif
  Endfor
  * Some other code where also there are few other returns ...
Endwith
*-- Evan would add here:
RETURN ( luReturnValue )

Endproc

This accomplishes EXACTLY the same end result with a SINGLE EXIT POINT, and does NOT slow the code down or make the code ANY LESS READABLE. It also does not restrict breaking the code down into "handler routines" as you suggest (which is what I also do -- great minds -g-).

Please, Cetin, I'm NOT saying I'm right and you're wrong, or even hinting that your code is anything less than excellent -- this is a *personal style* issue, and (as you correctly suggest) one we could debate forever without settling anything (g). My point is that IN THE INSTANCE YOU PROVIDE, I don't believe that multiple exit points are more efficient.

Evan


>Hi Mike,
>This is kind of issue that could be argued for a decade :)
>I don't think only the ones at the start are fine. Anywhere appearing a return might be fine as well. ie: Just at the moment there is some code I'm working on and that has a 'return .f.' in about the middle of the routine. I reread that code carefully and glad that I placed that there from the start :)
>Preventing 'abuse' of many returns might cause abuse of creating unnecessary variables/objects :)
>It's hard to decide how much is too many as it's hard to show a sample code that proves one is superior to other. For example if I pseudocode the current routine here :
>
>

>Procedure someproc
>Local ...
>With This
>  If !.GetValidDateRanges()
>    Return .F.
>  Endif
>  * Some other code ...
>  Select ... From ...Into Array .arrItems
>  If Type('.arrItems[1,1]')#'N'
>    Return .F.  && No items
>  Endif
>  For ix=1 To Alen(.arrItems,1)
>    If .arrItems[ix,2] = 'somecondition'
>      Return .SomeOtherProc(ix)
>    Endif
>    If .arrItems[ix,3] = 'somecondition2'
>      Return .SomeOtherProc2(ix)
>    Endif
>  Endfor
>  * Some other code where also there are few other returns ...
>Endwith
>Endproc
>

>This already has the code broken down into many handler routines. From my POV it's easier to follow this code then to follow 'one exit point' counterpart.
>Cetin
>
>
>>Hi Cetin
>>
>>It seems the issue here is having too many returns. The ones at the start that jump out when the most obvious stuff fails is fine.
>>
>>IMO the abuse of many returns will occur in the "meat" of the routine. This may be because there are too many kinds of meat in routines. Maybe if there are too many returns, that can be taken as indication that the routine should be broken down?
>>