What to return ?
oferco
what is better ? :
void foo() {
...
return;
}
OR:
void foo() {
... <== without return;/return(..)/exit(...) at the end
}
????
J. Benz
oferco wrote:
> Hello,
>
> what is better ? :
>
> void foo() {
>
> ...
>
> return;
I'll go out on a limb and say this is better. If for no other reason
than you've provided information about intent - you mean for the code to
return here and nowhere else. Without the return statement, a
maintainer has to assume you meant to fall off the end of the code -
with the return statement, the assumption is hard fact. There is,
however, no real technical difference I can see between the two. But
I've always held that it's bad style to fall off the end of a function
without an explicit return statement.
>
>
> }
>
> OR:
>
> void foo() {
>
> ... <== without return;/return(..)/exit(...) at the end
Obviously, you do *not* want exit() here. And the parens on the return
aren't needed either, not to mention that it would be an error if you
put any value between them in this context.
>
>
> }
>
> ????
Daniel Fischer
> what is better ? :
>
> void foo() {
> }
> OR:
> void foo() {
> }
The second: You don't need to explicitly return nothing.
--
Daniel Fischer
d...@freudenstadt.net
Szu-Wen Huang
: > what is better ? :
: >
: > void foo() {
: > return;
: > }
: > OR:
: > void foo() {
: > }
: The second: You don't need to explicitly return nothing.
I wish aloud that folks wouldn't answer issues of style with statements
of authority. In this particular case, another programmer just gave
the opposite answer. :)
Here are some additional observations:
1. It doesn't make a difference to the compiler.
2. A compiler will probably not warn you if you decide to use
the first form but forget one here or there. This is an
argument against the first form, because you don't have an
automated tool to help you enforce consistency.
Unfortunately, unless you work in a place with strict coding
standards that cover this specific topic, you'll have to make
your own decision.
Just like you made the hideous heretical decision to put the
opening brace on the same line as the function name. :)
Team Tropicana
> void foo() { return; }
>
> OR:
>
> void foo() { without return;/return(..)/exit(...) at the end }
It's a matter of style. Neither is better.
--
(initiator of the campaign for grumpiness where grumpiness is due)
(team tropicana)
Will Rose
: > what is better ? :
: >
: > void foo() {
: > return;
: > }
: > OR:
: > void foo() {
: > }
: The second: You don't need to explicitly return nothing.
Or the first: you need to make the return explicit for readability.
Or, of course, neither.
Lawrence Kirby
>
>
>oferco wrote:
>
>> Hello,
>>
>> what is better ? :
>>
>> void foo() {
>>
>> ...
>>
>> return;
>
>I'll go out on a limb and say this is better. If for no other reason
>than you've provided information about intent - you mean for the code to
>return here and nowhere else.
To me a return statement at the end of a functin says nothing about whether
there will be return statements in other parts of the function or not.
>Without the return statement, a
>maintainer has to assume you meant to fall off the end of the code -
It isn't really an assumption, there's no other choice, unless your're
referring to the possibility of an infinite loop.
>with the return statement, the assumption is hard fact. There is,
>however, no real technical difference I can see between the two. But
>I've always held that it's bad style to fall off the end of a function
>without an explicit return statement.
Strange, I've always disliked putting unnecessary return statements at
the end of functions. This is simply a style issue and highly
subjective.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Mike Smith
>Hello,
>
>what is better ? :
>
>void foo() {
>
> ...
>
> return;
>
>}
>
>
>void foo() {
>
> ... <== without return;/return(..)/exit(...) at the end
>
>}
>
I'm putting on my flame-proof suit, but IMO the best way is
int foo() {
...
if (successful_completion) return some_value;
else return some_other_value;
}
--
Mike Smith. No, the other one.
Mike Smith
>Not only I disagree changing "void foo" into "int foo", but also
>disagree adding one unnecessary "return;" at the end of void foo.
>
>1. Return something only when you need to do so. Don't return
>something just for fun.
Wouldn't you want to know whether your function completed properly or not?
Richard Stamp
>>something just for fun.
>
>Wouldn't you want to know whether your function completed properly or not?
It depends on whether the function is ever expected to fail and whether
there's anything we can do about the failure. If the only reason a function
can fail is due to an internal error (or something like invalid arguments),
then it may be more appropriate to abort the whole program if the error
occurs.
Certainly, a function which always returns the same value is somewhat
suspect (unless it's you-know-what, in which case there's no choice about
the matter).
Szu-Wen Huang
: Mike Smith wrote in message <75r1sk$kc7$1...@fir.prod.itd.earthlink.net>...[...]
: >>1. Return something only when you need to do so. Don't return
: >>something just for fun.
: >Wouldn't you want to know whether your function completed properly or not?
: It depends on whether the function is ever expected to fail and whether
: there's anything we can do about the failure. [...]
Both of these can be rather difficult to answer early in development.
Hardcoding otherwise void functions to return constant success values
at that stage enables us to write their callers to be sensitive to
possible failures.
In other words, if a function is declared void initially, and then
later expanded to return an int error value on failure, the callers
of such function will still compile (usually without warning), but
ignore any error conditions. If a function is declared int initially
but always returning success, you can always change it to void and
watch all the callers fail to compile (and thus easily find useless
code), or simply leave things as they are.
This of course depends on whether you use strict lint, your coding
habits, et al. I raise the above not as suggested rules, just as
possible uses of the practice.
Lawrence Kirby
kld_m...@NOSPAMearthlink.net "Mike Smith" writes:
>Parker Shaw wrote in message <3680E130...@usa.net>...
>>Not only I disagree changing "void foo" into "int foo", but also
>>disagree adding one unnecessary "return;" at the end of void foo.
>>
>>1. Return something only when you need to do so. Don't return
>>something just for fun.
>
>
>Wouldn't you want to know whether your function completed properly or not?
There are many function were the simple act of returning indicates that
the function completed properly. Adding a return value to such functions
(where they don't already return useful results) doesn't buy you anything.
is...@my-dejanews.com
> >1. Return something only when you need to do so. Don't return
> >something just for fun.
>
> Wouldn't you want to know whether your function completed properly or not?
In this case the condition "when you need to do so" applies. But,
why should, say "exit" or "abort", return something?
The most important rules about "return" (my own opinion):
1.) use *at most* one return per function.
2.) If return is used, it should be the very last statement.
3.) If a function returns void, then no return statement should
occur by the general rule: "If two possibilities are equivalent
then, when it is only a matter of style, use the shorter one."
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Parker Shaw
disagree adding one unnecessary "return;" at the end of void foo.
1. Return something only when you need to do so. Don't return
something just for fun.
2. Adding a "return;" at the end of void function tells nothing more
to the reader.
But, I know everyone has the right to choose, unless anti-
specification, like "void" a very famous function....
BTW, just personally, I really enjoy the answer of Lawrence.
--
________________________________________________
Parker Shaw | Make it correct
psh...@cs.auckland.ac.nz | Make it elegant
________________________________________________
Graeme Fenwick
> if (successful_completion) return some_value;
> else return some_other_value;
Yes, but is there any generally accepted set of values for most functions,
such as TRUE and FALSE for success and failure respectively? (That is, if we
don't need to consider returning anything else, which might limit our
options in that area?).
============================================
Graeme Fenwick | gfen...@BYESPAMprimex.co.uk
"Please remove BYESPAM filter when replying by mail"
-- WILLIAM SHAKESPEARE, Hamlet.
Will Rose
: Mike Smith wrote in message <75pb2n$hre$1...@holly.prod.itd.earthlink.net>...
: > if (successful_completion) return some_value;
: > else return some_other_value;
: Yes, but is there any generally accepted set of values for most functions,
: such as TRUE and FALSE for success and failure respectively? (That is, if we
: don't need to consider returning anything else, which might limit our
: options in that area?).
The Unix convention is to return FAILED, -1; and anything else is some
sort of status code. I tend to use OK, 1 as the 'opposite' of FAILED.
Graeme Fenwick
That's when you're returning values from main(), right? (And if so, surely
any sensible Unix C compiler would define EXIT_FAILURE as -1 anyway?)
For all functions except main(), 1 or 0 (for success or failure) still seem
the most logical return values to me. Unless standard programming practice
says something else, that is.
Will Rose
: Will Rose wrote in message <91453159...@optional.cts.com>...
: >Graeme Fenwick (gfen...@BYESPAMprimex.co.uk) wrote:
: >: Mike Smith wrote in message
: <75pb2n$hre$1...@holly.prod.itd.earthlink.net>...
: >: > if (successful_completion) return some_value;
: >: > else return some_other_value;
: >: Yes, but is there any generally accepted set of values for most
: functions,
: >: such as TRUE and FALSE for success and failure respectively? (That is, if
: we
: >: don't need to consider returning anything else, which might limit our
: >: options in that area?).
: >The Unix convention is to return FAILED, -1; and anything else is some
: >sort of status code. I tend to use OK, 1 as the 'opposite' of FAILED.
: That's when you're returning values from main(), right? (And if so, surely
: any sensible Unix C compiler would define EXIT_FAILURE as -1 anyway?)
: For all functions except main(), 1 or 0 (for success or failure) still seem
: the most logical return values to me. Unless standard programming practice
: says something else, that is.
No, main() returns only 0, EXIT_SUCCESS or EXIT_FAILURE. I just find it
clearer to use #defines to say exactly what I'm returning, and rather than
use TRUE/FALSE (which I treat as booleans) I prefer FAILED, OK, and whatever
other signifier that particular function might need. (eg. MAYBE).
FAILED with a value of -1 is common in Unix system calls, and OK is my own
convention.
Lawrence Kirby
gfen...@BYESPAMprimex.co.uk "Graeme Fenwick" writes:
>Will Rose wrote in message <91453159...@optional.cts.com>...
>>Graeme Fenwick (gfen...@BYESPAMprimex.co.uk) wrote:
>>: Mike Smith wrote in message
><75pb2n$hre$1...@holly.prod.itd.earthlink.net>...
>>: > if (successful_completion) return some_value;
>>: > else return some_other_value;
>>: Yes, but is there any generally accepted set of values for most
>functions,
>>: such as TRUE and FALSE for success and failure respectively? (That is, if
>we
>>: don't need to consider returning anything else, which might limit our
>>: options in that area?).
>>The Unix convention is to return FAILED, -1; and anything else is some
>>sort of status code. I tend to use OK, 1 as the 'opposite' of FAILED.
>
>That's when you're returning values from main(), right? (And if so, surely
>any sensible Unix C compiler would define EXIT_FAILURE as -1 anyway?)
A more sensible value is 1. Unix systems typically look at the low order
byte of the exit code so sensible values are in the range 0-255. It
can be confusing since some shells treat the value as a signed char, others
as unsigned.
>For all functions except main(), 1 or 0 (for success or failure) still seem
>the most logical return values to me. Unless standard programming practice
>says something else, that is.
The nice thing about standards is that you can pick the one that suits you.
Lawrence Kirby
gfen...@BYESPAMprimex.co.uk "Graeme Fenwick" writes:
>Mike Smith wrote in message <75pb2n$hre$1...@holly.prod.itd.earthlink.net>...
>> if (successful_completion) return some_value;
>> else return some_other_value;
>
>
>Yes, but is there any generally accepted set of values for most functions,
>such as TRUE and FALSE for success and failure respectively? (That is, if we
>don't need to consider returning anything else, which might limit our
>options in that area?).
You could use that but you then have to decide whether TRUE indicates that
function succeeded or failed. Something like OK and FAILED is clearer.
What often works well is to have a positive value indicating a return value
(like a length), a negative value indicating an error (you can use different
values to give an indication of the sort of error) and 0 can be a special
case (success but no data etc.) For consistency a 2 state case can use
values like 0 and -1.
Graeme Fenwick
it was intended to refer to functions except main().
I don't know a great deal about Unix, the return values that the various
shells would expect, how they treat it, and so on. (However, since I'm on
the subject... are EXIT_FAILURE and EXIT_SUCCESS always considered
acceptable (portable) return values, regardless of platform?).
Lawrence Kirby wrote in message <914788...@genesis.demon.co.uk>...
>>Yes, but is there any generally accepted set of values for most functions,
>>such as TRUE and FALSE for success and failure respectively? (That is, if
we
>>don't need to consider returning anything else, which might limit our
>>options in that area?).
>You could use that but you then have to decide whether TRUE indicates that
>function succeeded or failed. Something like OK and FAILED is clearer.
>What often works well is to have a positive value indicating a return value
>(like a length), a negative value indicating an error (you can use
different
>values to give an indication of the sort of error) and 0 can be a special
>case (success but no data etc.) For consistency a 2 state case can use
>values like 0 and -1.
Less than coincidentally (probably!) I noticed another function recently
that used the same scheme, so I'll bear that in mind.
[from other post]
>The nice thing about standards is that you can pick the one that suits you.
Kind of defeats the purpose if you have too many though ;-)
Seems like, if nothing else, it's a good idea to at least try to be
consistent.
Will Rose
Graeme Fenwick (gfen...@BYESPAMprimex.co.uk) wrote:
: First off, I'm sorry if my initial post in this thread was a bit misleading-
: it was intended to refer to functions except main().
: I don't know a great deal about Unix, the return values that the various
: shells would expect, how they treat it, and so on. (However, since I'm on
: the subject... are EXIT_FAILURE and EXIT_SUCCESS always considered
: acceptable (portable) return values, regardless of platform?).
Yes. The C standard defines 0, EXIT_SUCCESS, and EXIT_FAILURE as acceptable
values to return from main(). That is the meaning of portability in the
context of this newsgroup.
Older Unix programs, for instance, will often return 0 from main() for
success (hence the grandfathered 0 in the standard) and any value other
than 0, typically 1, for failure. Shells, I'm pretty sure, mostly treat
the return value as an unsigned 8 bit, so returning -1 from main may get
you 255 at the shell. Stick to returning small positive integers - Posix
probably defines a valid range.
Any function other than main(), and you can do whatever you want.