Thanks for explanation - matched with my guess :)
Cetin
>Hi Çetin
>
>>I unfortuantely cannot understand 'meat of routine' ( an idiom ? ) but guess what it means :)
>
>Meat of the routine is an idiom. I think it has to do with fancy dinners. There are little appetizers before the main course (a nice meaty steak). If you're like me, you bypass the appetizers because they get in the way of the steak ;)
>
>>Anyway I greatly sense (from your posts I've seen) our coding styles are very similar and you'd accept any sample I send as if it was yours :)
>
>Unfortunately, I'm becoming doubtful of that. Many times, the idea of personal preference / style is brought up. Is there style involved in laying out electrical circuits? I think many are too married to their style.
>"I don't like how it looks" is not an objective argument.
>
>>PS: If I'm right you're also not bound to 'one exit point'.
>
>That may be open to interpretation.
>
>A routine is supposed to accomplish a task. There are conditions that would prevent the routine from functioning. I propose to deal with those conditions before the main part of the routine.
>
>Apply the same rule in a DO...ENDDO. If the DO...ENDDO is supposed to do a task, anything that would fail the entire task deserves an EXIT, any records that should be skipped over deserve a LOOP. The main part of the loop will always be clearer, stripped of non-essentials.
>
>I'd prefer to have only one exit point from the main part of the routine, but not if I have to go to any lengths to do it.
>
>>Cetin
>>
>>>Hi Cetin
>>>
>>>In this case, you're bailing out before the meat of the routine! So I'm alright with it.
>>>
>>>>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.
>>>> 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?
>>>>>
