the c# return statement

[John Bailo]

The c# *return* statement has been bothering me the past few months.

I don't like the fact that you can have different code paths in a method
and have multiple return statements. To me, it would be more orthogonal
if a method could only have one return statement.




--
W '04 <:> Open Source

[Tom B.]

Re: the c# return statement

John Bailo wrote:
[color=blue]
> The c# *return* statement has been bothering me the past few months.
>
> I don't like the fact that you can have different code paths in a method
> and have multiple return statements. To me, it would be more orthogonal
> if a method could only have one return statement.[/color]

To some extent, I share this sentement :-) I find that
Delphi's/Pascal's 'result' returning mechanism is more elegant, for the
most part. However, I think there are /some/ instances where returning
before the end of a method can produce more straight-forward code.

Example of Delphi's/Pascal's returning mechanism:

function Foo: Boolean;
begin
Result := True;
if FooBar then
Result := GiveMeABoolean( );
DoSomethingElse ();
end; // return value is value of Result

Of course, this can easily be simulated in C# (but it involves more
statements, generally):

bool Foo()
{
bool result = true;

if (fooBar)
result = GiveMeABoolean( );
DoSomethingElse ();

return result;
}

Or even better, in this case:

bool Foo()
{
bool result = fooBar ? GiveMeABoolean( ) : true;
DoSomethingElse ();
return result;
}

I guess I don't mind the C-style returning mechanism so much if it's not
abused (in my opinion, according to my own personal style), but find
Delphi's/Pascal's equivalent more elegant in most cases.

[mlw]

Re: the c# return statement

John Bailo wrote:
[color=blue]
>
> The c# *return* statement has been bothering me the past few months.
>
> I don't like the fact that you can have different code paths in a method
> and have multiple return statements. To me, it would be more orthogonal
> if a method could only have one return statement.
>[/color]

The C# language is very much based on C++ and Java, multiple return
statements are part of the language.

If you have a problem with multiple return statements, don't use them.

[Donovan Rebbechi]

Re: the c# return statement

In article <26a5ed68577bc6 37437dd356fb312 9d2@news.terane ws.com>, John Bailo wrote:[color=blue]
>
> The c# *return* statement has been bothering me the past few months.
>
> I don't like the fact that you can have different code paths in a method
> and have multiple return statements. To me, it would be more orthogonal
> if a method could only have one return statement.[/color]

If you have exceptions, you can have different paths in a method. So unless
you're prepared to do without exceptions and check return codes every time
you tie your shoelaces, you're stuck with the perceived evils of multiple paths.

Cheers,
--
Donovan Rebbechi

http://pegasus.rutgers.edu/~elflord/

[Tom B.]

Re: the c# return statement

Donovan Rebbechi wrote:
[color=blue]
> In article <26a5ed68577bc6 37437dd356fb312 9d2@news.terane ws.com>, John Bailo wrote:
>[color=green]
>>The c# *return* statement has been bothering me the past few months.
>>
>>I don't like the fact that you can have different code paths in a method
>>and have multiple return statements. To me, it would be more orthogonal
>>if a method could only have one return statement.[/color]
>
> If you have exceptions, you can have different paths in a method. So unless
> you're prepared to do without exceptions and check return codes every time
> you tie your shoelaces, you're stuck with the perceived evils of multiple paths.[/color]

As I say, I agree with JB to some extent in that I don't generally like
returning from methods /before/ the end, with a 'return' statement.
However, I don't feel the same with throwing exceptions since, if one's
using them correctly, one'll only be throwing them in /exceptional/
circumstances anyway, in which case one would have no desire *not* to
return from the method there and then.

[Milo T.]

Re: the c# return statement

On Thu, 08 Apr 2004 22:33:22 GMT, John Bailo wrote:
[color=blue]
>
> The c# *return* statement has been bothering me the past few months.
>
> I don't like the fact that you can have different code paths in a method
> and have multiple return statements. To me, it would be more orthogonal
> if a method could only have one return statement.[/color]

You mean "simpler", not "orthogonal ".

And it's only simpler if the logic in the function is simple. Once it gets
complex, it makes more sense to return at the point a return is required -
not waiting until later and setting up all kinds of flags and variables to
stash state until you hit the return statement.

Unless you're suggesting that a goto statement to the return would be ok?
--
People in the killfile (and whose posts I won't read) as of 4/8/2004
6:10:03 PM:
Peter Kohlmann, T.Max Devlin. Matt Templeton (scored down)

[Donovan Rebbechi]

Re: the c# return statement

In article <1mfz4ihxdp3m4$ .a483thyh7rrn$@ fanatastical.ma laprop.net>, Milo T. wrote:[color=blue]
> On Thu, 08 Apr 2004 22:33:22 GMT, John Bailo wrote:
>[color=green]
>>
>> The c# *return* statement has been bothering me the past few months.
>>
>> I don't like the fact that you can have different code paths in a method
>> and have multiple return statements. To me, it would be more orthogonal
>> if a method could only have one return statement.[/color]
>
> You mean "simpler", not "orthogonal ".
>
> And it's only simpler if the logic in the function is simple. Once it gets[/color]

To me, very long and complex functions in an OOP language usually indicates
messy coding. One can usually break up the logic into smaller functions.
If the complexity of passing all the local data to these functions is
prohibitive (this is one of the main reasons functions aren't subdivided,
especially in C), it's usually a sign that you need group some of this data
into objects.
[color=blue]
> complex, it makes more sense to return at the point a return is required -
> not waiting until later and setting up all kinds of flags and variables to
> stash state until you hit the return statement.
>
> Unless you're suggesting that a goto statement to the return would be ok?[/color]

Nah. He was thinking of wrapping the function body in a try block.

Cheers,
--
Donovan Rebbechi

http://pegasus.rutgers.edu/~elflord/

[Linønut]

Re: the c# return statement

Error BR-549: MS DRM 1.0 rejects the following post from Tom B.:
[color=blue]
> John Bailo wrote:
>
> Example of Delphi's/Pascal's returning mechanism:
>
> function Foo: Boolean;
> begin
> Result := True;
> if FooBar then
> Result := GiveMeABoolean( );
> DoSomethingElse ();
> end; // return value is value of Result[/color]

Get that ugly crap offa my screen!

<hyperventilate s>

I'm no longer using Builder.
I'm no longer using Builder.
I'm no longer using Builder.

--
I tried to read "Dune" but found it a little dry.

[Linønut]

Re: the c# return statement

Error BR-549: MS DRM 1.0 rejects the following post from Donovan Rebbechi:
[color=blue]
> In article <26a5ed68577bc6 37437dd356fb312 9d2@news.terane ws.com>, John Bailo
> wrote:[color=green]
>> I don't like the fact that you can have different code paths in a method and
>> have multiple return statements. To me, it would be more orthogonal if a
>> method could only have one return statement.[/color]
>
> If you have exceptions, you can have different paths in a method. So unless
> you're prepared to do without exceptions and check return codes every time
> you tie your shoelaces, you're stuck with the perceived evils of multiple paths[/color]

Multiple paths can be evil in complete code or code that is dominated by such
paths. I can still remember unrolling some Cosmic FORTRAN code into decent
structured C code.

If a routine fits on the screen, you can pretty much get away with anything.

--
Trust your data to a Linux server or desktop!

[Jon Skeet [C# MVP]]

Re: the c# return statement

[Removed comp.os.linux.a dvocacy, which is completely irrelevant here.]

John Bailo <jabailo@earthl ink.net> wrote:[color=blue]
> The c# *return* statement has been bothering me the past few months.
>
> I don't like the fact that you can have different code paths in a method
> and have multiple return statements. To me, it would be more orthogonal
> if a method could only have one return statement.[/color]

I disagree. For instance, here's a piece of code I've been using in a
thread on the C# newsgroup recently:

public static bool IsDecimal (string data)
{
bool gotPoint = false;

foreach (char c in data)
{
if (c=='.')
{
if (gotPoint)
{
return false;
}
gotPoint = true;
continue;
}
if (c < '0' || c > '9')
{
return false;
}
}
return true;
}

(This isn't designed to be culture-sensitive, or work with +/- etc -
it's just an example.)

To avoid multiple returns, you end up having to introduce another local
variable, and break out of the loop when you know what the result is
going to be. You could do the breaking part using a while loop instead,
but then the iteration becomes less readable. Either way, you've still
got the extra local variable.

The way I see it, "return" is a powerful way of saying "If you've got
here, you know the result of the method - none of the rest of the
code/state is relevant."

As others have mentioned, if you don't like using it, you don't have to
- you can always put that extra local variable in, along with all the
breaks you need, and then return at the end of the method. No-one's
forcing you to write code like the above - but I'm glad I'm not being
forced *not* to write it, either.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Milo T.]

Re: the c# return statement

On Fri, 9 Apr 2004 02:39:43 +0000 (UTC), Donovan Rebbechi wrote:
[color=blue]
> In article <1mfz4ihxdp3m4$ .a483thyh7rrn$@ fanatastical.ma laprop.net>, Milo T. wrote:[color=green]
>> On Thu, 08 Apr 2004 22:33:22 GMT, John Bailo wrote:
>>[color=darkred]
>>>
>>> The c# *return* statement has been bothering me the past few months.
>>>
>>> I don't like the fact that you can have different code paths in a method
>>> and have multiple return statements. To me, it would be more orthogonal
>>> if a method could only have one return statement.[/color]
>>
>> You mean "simpler", not "orthogonal ".
>>
>> And it's only simpler if the logic in the function is simple. Once it gets[/color]
>
> To me, very long and complex functions in an OOP language usually indicates
> messy coding. One can usually break up the logic into smaller functions.
> If the complexity of passing all the local data to these functions is
> prohibitive (this is one of the main reasons functions aren't subdivided,
> especially in C), it's usually a sign that you need group some of this data
> into objects.[/color]

Yes, generally I would agree but sometimes breaking things down into
objects is something you don't want to or cannot do (for performance
reasons).

Besides, I find the first clearer than the second personally...

ValueType Function(EnumTy pe a) {

switch(a)
{
case 1:
{
DoSomething();
DoSomethingElse ();
return DoSomethingNew( );
}
default:
ASSERT("Shouldn 't reach here - bad switch value");
// intentional fallthrough
case 2:
{
DoSomething();
DoSomethingElse ();
return DoSomethingNew( );
}
}

}

ValueType Function(EnumTy pe a) {

ValueType v;

switch(a)
{
case 1:
{
DoSomething();
DoSomethingElse ();
v=DoSomethingNe w();
break;
}
default:
ASSERT("Shouldn 't reach here - bad switch value");
// intentional fallthrough
case 2:
{
DoSomething();
DoSomethingElse ();
v=DoSomethingNe w();
break;
}
}

return v;

}


--
People in the killfile (and whose posts I won't read) as of 4/9/2004
12:11:27 AM:
Peter Kohlmann, T.Max Devlin. Matt Templeton (scored down)

[John Bailo]

Re: the c# return statement

Milo T. wrote:
[color=blue]
> On Fri, 9 Apr 2004 02:39:43 +0000 (UTC), Donovan Rebbechi wrote:
>[color=green]
>> In article <1mfz4ihxdp3m4$ .a483thyh7rrn$@ fanatastical.ma laprop.net>, Milo
>> T. wrote:[color=darkred]
>>> On Thu, 08 Apr 2004 22:33:22 GMT, John Bailo wrote:
>>>
>>>>
>>>> The c# *return* statement has been bothering me the past few months.
>>>>
>>>> I don't like the fact that you can have different code paths in a
>>>> method
>>>> and have multiple return statements. To me, it would be more
>>>> orthogonal if a method could only have one return statement.
>>>
>>> You mean "simpler", not "orthogonal ".
>>>
>>> And it's only simpler if the logic in the function is simple. Once it
>>> gets[/color]
>>
>> To me, very long and complex functions in an OOP language usually
>> indicates
>> messy coding. One can usually break up the logic into smaller functions.
>> If the complexity of passing all the local data to these functions is
>> prohibitive (this is one of the main reasons functions aren't subdivided,
>> especially in C), it's usually a sign that you need group some of this
>> data into objects.[/color]
>
> Yes, generally I would agree but sometimes breaking things down into
> objects is something you don't want to or cannot do (for performance
> reasons).
>
> Besides, I find the first clearer than the second personally...
>
> ValueType Function(EnumTy pe a) {
>
> switch(a)
> {
> case 1:
> {
> DoSomething();
> DoSomethingElse ();
> return DoSomethingNew( );
> }
> default:
> ASSERT("Shouldn 't reach here - bad switch value");
> // intentional fallthrough
> case 2:
> {
> DoSomething();
> DoSomethingElse ();
> return DoSomethingNew( );
> }
> }
>
> }
>
> ValueType Function(EnumTy pe a) {
>
> ValueType v;
>
> switch(a)
> {
> case 1:
> {
> DoSomething();
> DoSomethingElse ();
> v=DoSomethingNe w();
> break;
> }
> default:
> ASSERT("Shouldn 't reach here - bad switch value");
> // intentional fallthrough
> case 2:
> {
> DoSomething();
> DoSomethingElse ();
> v=DoSomethingNe w();
> break;
> }
> }
>
> return v;
>
> }
>
>[/color]

See, that's exactly what I don't like -- having conditional multiple
returns.

What I propose is the following for a method declaration, which is normally:


public type funname(type param)

would now be

public @returnVar=null type funname(type param)

in this case, @returnVar is declared as part of the general declaration and
so is inherent in the the method, as well as it's default value. thus
funname can never not return a value or have an ambiguous code path. yet,
within the method the value of @returnVal can be continuously redefined.








--
W '04 <:> Open

[Whelp]

Re: the c# return statement

Tom B. wrote:
[color=blue]
> Or even better, in this case:
>
> bool Foo()
> {
> bool result = fooBar ? GiveMeABoolean( ) : true;
> DoSomethingElse ();
> return result;
> }[/color]

I like:
bool Foo()
{
bool result = !foobar || GiveMeABoolean( );
DoSomethingElse ();
return result;
}

ACK on the C/Pascal style thing.

Regards,
Whelp

[cody]

Re: the c# return statement

> The c# *return* statement has been bothering me the past few months.[color=blue]
>
> I don't like the fact that you can have different code paths in a method
> and have multiple return statements. To me, it would be more orthogonal
> if a method could only have one return statement.[/color]


even in pascal/delphi you can prematurely exit a method which often is
useful.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Donovan Rebbechi]

Re: the c# return statement

In article <1wz6yoaop9nv0. 1oqbftjh5dyny$@ fanatastical.ma laprop.net>, Milo T. wrote:
[color=blue]
> Yes, generally I would agree but sometimes breaking things down into
> objects is something you don't want to or cannot do (for performance
> reasons).[/color]

Seriously ? I mean, can't a switch be performed via table lookup as opposed to
an if/then/else ?

switch is one of my least favourite constructs in code. It can always be
replaced with table lookup or polymorphism. Both of these would better
address the "bad switch value" issue.

Cheers,
--
Donovan Rebbechi

http://pegasus.rutgers.edu/~elflord/