Evan,
"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)."
Yes this is what I said too.
I once again say it's pure personal preference and as I said to Mike we could argue on this subject for a decade.

As per the revised code with 'one exit point' it wouldn't work and the result might be only the same by coincidence (and you've a great chance to return same result with a .t./.f. case only). But if the functions were doing write operations too though you get the same result by coincidence you might end up with screwed data. It'd be less efficient I can say for sure. OTOH with some longer coding it could be made to 'one exit point' style (and it would be less efficient at least just for it created the unnecessary luReturnValue variable if nothing else - with more memory and faster computers we're less careful about these slight efficiences and could be negligible).

  Select ... From ...Into Array .arrItems
  If Type('.arrItems[1,1]')#'N'
    *-- Evan would replace
    * Return .F.  && No items
    *-- with
    luReturnValue = .F.

* This one is OK 
* assuming I'd have some kind of do nothing down the code till return
* and something to signal for..endfor should be skipped - 
* another if..endif wrapper :( or moving the code in this block
* Personally I hate the need to browse till the end of routine
* to see I was doing nothing else more before returning the .f. in this case

  Endif
  For ix=1 To Alen(.arrItems,1)
    If .arrItems[ix,2] = 'somecondition'
      *-- Evan would replace
      * Return .SomeOtherProc(ix)
      *-- with
      luReturnValue = .SomeOtherProc(ix)

* My original code cuts processing any more elements here and returns
* Assuming it was a typo you forgot to put an 'exit'

    Endif
    If .arrItems[ix,3] = 'somecondition2'
      *-- Evan would replace
      * Return .SomeOtherProc2(ix)
      *-- with
      luReturnValue = .SomeOtherProc2(ix)
    Endif
  Endfor

* W/o typo no 'exit' in loop
* Unnecessarily .SomeOtherProc and .SomeOtherProc2 might be called
* multiple times and last call might set the return value
* just the reverse of what should it be
* Still you need revise the code more as luReturnValue
* doesn't give any hint on if the rest of code should be processed or not
* Revising the code and placing more if..else..endif code would do it

Cetin

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