[Tutor] Multiple exits in a function...

[Alan Trautman]

In this case they should call the same exit function. Especially if you do
any cleanup or logging. If they use different functions for each exit, do
you really want to maintain two exit functions? Or as happens more often you
forget one and that's the one your users will use causing a problem that
will be very hard to troubleshoot.


Any multiple exits is hard to follow any frequently leads to overly
complicated functions that should be simplified. As with everything there
are exceptions (menu handling functions) but generally this is fairly
accepted especially among people who have to maintain the code later. This
frequently can be handled by creating a decent flowchart of you program and
you'll quickly find how difficult these are to explain.

Mostly my opinion I know but it will be interesting to see what others say.

Alan



-----Original Message-----
From: Stanfield, Vicki {D167~Indianapolis}
[mailto:VICKI.STANFIELD at ROCHE.COM]
Sent: Friday, October 24, 2003 9:50 AM
To: tutor at python.org
Subject: RE: [Tutor] Multiple exits in a function...


Is it considered wrong then to have Exit on the menubar and another exit in
the code?

--vicki

-----Original Message-----
From: Mike Hansen [mailto:mhansen at cso.atmel.com]
Sent: Friday, October 24, 2003 9:29 AM
To: tutor at python.org
Subject: [Tutor] Multiple exits in a function...


I'm curious about this. A co-worker was ranting recently while debugging 
some C code that it had multiple exits. (BTW: It wasn't my C code. I 
have never written C code except in college.)

I trend to write my functions with multiple exits. Usually when some 
test fails, I spit a message(email, print it, or write it to a log file) 
and get out of dodge. The alternative is usually horrible nested If 
statements even if I flip the logic around. Which to me makes it hard to 
read and maintain.

Can you point me to some resources to help me wrap my mind around this? 
Code examples? ...

Thanks,

Mike

>
> Subject:
> Re: [Tutor] Re: Request for code critique ['break' vs control flag]
> From:
> "Alan Gauld" <alan.gauld at blueyonder.co.uk>
> Date:
> Thu, 23 Oct 2003 06:00:22 +0100
> To:
> "Danny Yoo" <dyoo at hkn.eecs.berkeley.edu>
>
>
>>>whence into many other languages) which breaks the rules of
>>>      
>>>
>structured
>  
>
>>>programming and by so doing makes code more difficult to read
>>>      
>>>
>reliably.
>
>  
>
>>But I've also met a lot of respected programmers who insist on the
>>    
>>
>"one
>  
>
>>entry point, and one exit point" viewpoint. 'break' drives them
>>    
>>
>crazy.
>  
>
>>So, like many style guidelines, it's a controversial issue. *grin*
>>    
>>
>
>I think the issue is that this is NOT a style thing. It's
>one of the basic tenets of structured programming and based
>on actual hard data. Having multiple exit points makes code
>harder to comprehend and hence more prone to error.
>
>Sometimes people forget the reasons behind some of these
>early discoveries in Computer Science. In fact I just finished
>reviewing a book by Robert Glass: "Facts and Fallacies of
>Software Engineering" which is based entirely on the concept
>that the faddy world of SE regularly forgets (and subsequently
>rediscovers) some of the basic truths of our trade...
>
>It falls into the same category as indentation style for
>begin/end or {} block markers. People treat it as a personal
>choice but hard evidence exists which shows that some styles
>are significantly more comprehensible than others.
>
>Alan G.
>
>  
>
>


_______________________________________________
Tutor maillist  -  Tutor at python.org
http://mail.python.org/mailman/listinfo/tutor

_______________________________________________
Tutor maillist  -  Tutor at python.org
http://mail.python.org/mailman/listinfo/tutor