Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
One exit per procedure/function/codeblock to what purpos
Message
De
09/10/2003 06:38:19
Cetin Basoz
Engineerica Inc.
Izmir, Turquie
 
 
À
08/10/2003 17:45:35
Mike Yearwood
Toronto, Ontario, Canada
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00835552
Message ID:
00836699
Vues:
24
Hi Mike,
I unfortuantely cannot understand 'meat of routine' ( an idiom ? ) but guess what it means :)
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 :)
PS: If I'm right you're also not bound to 'one exit point'.
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.  && 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?
>>>
Çetin Basöz

The way to Go
Flutter - For mobile, web and desktop.
World's most advanced open source relational database.
.Net for foxheads - Blog (main)
FoxSharp - Blog (mirror)
Welcome to FoxyClasses

LinqPad - C#,VB,F#,SQL,eSQL ... scratchpad
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform