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?
>>>Hi Jim,
>>>
>>>SET SOAPBOX ON
>>>SET BAD MEMORIES ON
>>>
>>>
>>>I ***ABSOLUTELY SUBSCRIBE*** to the "one exit point" approach, and *ALL* my code follows this.
>>>
>>>Why? Simple answer -- because someone besides myself might have to read AND understand my code one day.
>>
>>Hi Evan,
>>
>>While I sympathize with you, I have to disagree IF you imply that a single exit point ALWAYS gives more readable code. If the programmer is forced to adhere to a 'single exit point' standard, then there will occasionally be many IF constructions, not only causing multiple indents, but also forcing the reader to browse to the ELSE section in order to understand what's happening. The reader/programmer will have to do a lot of page-browsing up and down, which will not improve understanding. One can only hope that the 'negative' condition (the condition that should directly lead to the door) is dealt with first in the IF and the positive condition is handles in the ELSE. Compare:
>>
IF <value found>
>> IF <some other value found>
>> <real code>
>> ...
>> ...
>> ...
>> ...
>> ...
>> ELSE
>> * quit this function
>> ENDIF
>>ELSE
>> * quit this function
>>ENDIF
>>
IF <value not found>
>> * quit this function
>>ELSE
>> IF <some other value not found>
>> * quit this function
>> ELSE
>> <real code>
>> ...
>> ...
>> ...
>> ...
>> ...
>> ENDIF
>>ENDIF
>
>Peter,
>Strongly agree. I too doesn't follow the 'one exit point' rule or even don't accept it as a rule but as pure preference.
>From readability point I find it much easier to follow code that has 'early' returns :)
>Cetin
