Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Multiple return statements Vs goto's

Reply
Thread Tools

Multiple return statements Vs goto's

 
 
Dave Thompson
Guest
Posts: n/a
 
      05-31-2005
On Wed, 18 May 2005 19:56:35 +0100, Chris Croughton
<(E-Mail Removed)> wrote:

<snip: "too big" routines>
> (The original criterion I learned was "fit on a lineprinter page" -- 66
> lines. By coincidence, that's very close to the normal terminal window
> size I use...)
>

(The former) only if you lined it up yourself very very carefully, for
the overwhelmingly common case of 11" * 6lpi. With usual alignment you
could safely use 10" = 60 lines with .5" margins top and bottom, but
many printout/listing utilities not to mention compiler listings would
take one or two or even more of those lines for headers and labels and
markings. So <50-55 was IME the rule.

> I tend to return early for parameter checks, it saves a lot of nested
> conditionals and is usually clearer than the "fall through to a common
> exit". <snip>


Concur. And for me, also special cases sometimes but pretty rarely.

- David.Thompson1 at worldnet.att.net
 
Reply With Quote
 
 
 
 
Chris Croughton
Guest
Posts: n/a
 
      05-31-2005
On Tue, 31 May 2005 03:49:07 GMT, Dave Thompson
<(E-Mail Removed)> wrote:

> On Wed, 18 May 2005 19:56:35 +0100, Chris Croughton
> <(E-Mail Removed)> wrote:
>
> <snip: "too big" routines>
>> (The original criterion I learned was "fit on a lineprinter page" -- 66
>> lines. By coincidence, that's very close to the normal terminal window
>> size I use...)
>>

> (The former) only if you lined it up yourself very very carefully, for
> the overwhelmingly common case of 11" * 6lpi. With usual alignment you
> could safely use 10" = 60 lines with .5" margins top and bottom, but
> many printout/listing utilities not to mention compiler listings would
> take one or two or even more of those lines for headers and labels and
> markings. So <50-55 was IME the rule.


True, I should have said "not more than 66 lines" (some compilers
insisted on a special "page throw" comment which took up an extra line
as well). The terminal window in which I am typing this is 64 lines
(and vi takes the bottom line for status and commands) which is very
similar (except that I don't have to punch the cards myself and wait a
week or more for the lineprinter output <g>)...

>> I tend to return early for parameter checks, it saves a lot of nested
>> conditionals and is usually clearer than the "fall through to a common
>> exit". <snip>

>
> Concur. And for me, also special cases sometimes but pretty rarely.


Pragmatism. Not to be confused with #pragmatism <g>...)

Chris C
 
Reply With Quote
 
 
 
 
Mark
Guest
Posts: n/a
 
      05-31-2005

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> In some functions where i need to return multiple error codes at
> multiple places, I use multiple return statements. Say for ex.
> if (Found == 1)
> {
> if (val == -1)
> return error1;
> }
> else
> {
> if (val2 == -1)
> return error2;
> }
> return success;
> This is just a simple example. My case have lot of conditional
> statements.
>
> the alternate approach is to use goto statements. Let me know the
> better way of doing this and which is preferrable (multiple return
> statements or Goto's)


I don't like either approaches...
My preference would be to see:

....
int ret = success;
if(Found == 1)
ret = error1;
else if(val2 == -1)
ret = error2;
return ret;
....

Prevents the need of goto statements OR multiple returns...
both of which I try to avoid whenever possible!

Mark


 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      05-31-2005
In article <4P1ne.10404$(E-Mail Removed)>,
Mark <(E-Mail Removed)> wrote:

>My preference would be to see:


>...
>int ret = success;
>if(Found == 1)
> ret = error1;
>else if(val2 == -1)
> ret = error2;
>return ret;
>...


Your logic fails to success -- that is, success is assumed until
it is disproved. In most cases, it is better assume failure and only
assert success when one is sure that the conditions are acceptable.
--
Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec
 
Reply With Quote
 
Mark
Guest
Posts: n/a
 
      05-31-2005

"Walter Roberson" <(E-Mail Removed)-cnrc.gc.ca> wrote in message
news:d7i9ui$3og$(E-Mail Removed)...
> In article <4P1ne.10404$(E-Mail Removed)>,
> Mark <(E-Mail Removed)> wrote:
>
>>My preference would be to see:

>
>>...
>>int ret = success;
>>if(Found == 1)
>> ret = error1;
>>else if(val2 == -1)
>> ret = error2;
>>return ret;
>>...

>
> Your logic fails to success --

Take another look at the OP's code (the part you snipped)
I fail to success because in his example, that is what he wanted.



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
if statements and case statements questions John Crichton Ruby 6 07-12-2010 06:17 PM
Prepare Statements VS Statements Vince Java 12 01-21-2008 01:18 PM
repeated code before multiple return statements Alexander Stoyakin C Programming 14 07-29-2007 09:25 PM
component statements within architecture statements Neil Zanella VHDL 8 10-20-2006 09:05 AM
if statements with or w/o else statements Harry George Python 6 02-23-2004 06:48 PM



Advertisments