simple coding style question

"." <.@.com> wrote...

> If I have a method, is it better to write it so it has a
> single exit point and is (marginally) more complicated or
> so it has more than one exit point eg:

[snipped]

> Or does it come down to personal prefference?

If it's only in these minor methods, where the flow can be seen in one
glance, it really comes down to your own personal preference (or if the
department have a dierct coding standard). In these examples it can be
slightly more efficient to make use of more exit points, as you don't have
to make the extra statements for storing the results.

However, to build larger methods, there's the old but functioning concept of
modelling the flow with "Jackson Structured Programming" (another thing with
the acronym JSP, but not to be confused with JavaServer Pages).

If you or your department are using that, it surely would simplify things to
have just one singular exit-point, as this type of models doesn't even allow
multiple exit points.

// Bjorn A

Reply to this Message

> If I have a method, is it better to write it so it has a single exit point
> and is (marginally) more complicated or so it has more than one exit point

The correct answer to that question is yes. It is better to write it so
that it has one exit point or so it has more than one exit point. ;-)

One cannot say that one is always better than the other. You choose the
one that is most readable and clearly. Having a single exit point is
often better, but not always (despite what the zealots will tell you).

> public int crap(int data){
> int result;
[quoted text clipped - 17 lines]
> }
> }

Here are 2 other alternatives:

public int crap( int data )
{
int result = data;

if( data <= 0 )
{
result = -1;
}

return result;
}

I would favor this over your choices. It has one exit point and the if
only handles the exceptional case.

public int crap( int data )
{
if( data <= 0 )
{
return -1;
}

return data;
}

I think this one is a very poor choice. If you *are* going to have
multiple exit points then it is best to make it obvious by using control
structures as you did with the if-else. The example here is so simple
that it makes little difference, but in more real code the more clues
you can give to the reader the more readable the code will be.

> Or does it come down to personal prefference?

NO! NO! NO! It does not come down to personal preference! It comes down
to making the code as readable as possible. That often requires looking
beyond your personal preference and trying to come up with rules that
say always do so-and-so.

Signature

Dale King

Reply to this Message

> If I have a method, is it better to write it so it has a single exit point
> and is (marginally) more complicated or so it has more than one exit point

The correct answer to that question is yes. It is better to write it so
that it has one exit point or so it has more than one exit point. ;-)

One cannot say that one is always better than the other. You choose the
one that is most readable and clearly. Having a single exit point is
often better, but not always (despite what the zealots will tell you).

> public int crap(int data){
> int result;
[quoted text clipped - 17 lines]
> }
> }

Here are 2 other alternatives:

public int crap( int data )
{
int result = data;

if( data <= 0 )
{
result = -1;
}

return result;
}

I would favor this over your choices. It has one exit point and the if
only handles the exceptional case.

public int crap( int data )
{
if( data <= 0 )
{
return -1;
}

return data;
}

I think this one is a very poor choice. If you *are* going to have
multiple exit points then it is best to make it obvious by using control
structures as you did with the if-else. The example here is so simple
that it makes little difference, but in more real code the more clues
you can give to the reader the more readable the code will be.

> Or does it come down to personal prefference?

NO! NO! NO! It does not come down to personal preference! It comes down
to making the code as readable as possible. That often requires looking
beyond your personal preference and trying to come up with rules that
say always do so-and-so.

Signature

Dale King

Reply to this Message

Thomas G. Marshall - 17 Jun 2005 22:42 GMT

Dale King coughed up:

>> If I have a method, is it better to write it so it has a single exit
>> point and is (marginally) more complicated or so it has more than
[quoted text clipped - 7 lines]
> is often better, but not always (despite what the zealots will tell
> you).

Boy does *this* smell like another thread we've been subjected to
recently...

In any case, the multiple returns mechanism is often the clearest and most
maintainable. When that is the case, then use it. Otherwise, you'll
/often/ be building in status managing contrivances that can break over
time.

By the way, IIRC and FWIW, I think even the worst zealots allowed for
mid-procedure returns so long as they're part of the parameter checking.

Signature

Having a dog that is a purebred does not qualify it for breeding. Dogs
need to have several generations of clearances for various illnesses
before being bred. If you are breeding dogs without taking care as to
the genetic quality of the dog (again, being purebred is *not* enough),
you are what is known as a "backyard breeder" and are part of the
problem. Most of the congenital problems of present day dogs are
traceable directly to backyard breeding. Spay or neuter your pet
responsibly, and don't just think that you're somehow the exception and
can breed a dog without taking the care described.

Reply to this Message

Eric Sosman - 17 Jun 2005 23:10 GMT

> Dale King coughed up:
>
[quoted text clipped - 20 lines]
> By the way, IIRC and FWIW, I think even the worst zealots allowed for
> mid-procedure returns so long as they're part of the parameter checking.

Besides, "one and only one exit point" mixes poorly with
methods that exit by throwing an exception, especially if the
exception actually comes from a method further down the stack:

    int method(BufferedReader rdr) throws IOException {
    String line = rdr.readLine(); // exit point?!
    ...
    return 42; // exit point
    }

One *could* always do

    int method(BufferedReader rdr) throws IOException {
    IOException except = null;
    try {
    String line = rdr.readLine();
    ...
    }
    catch (IOException e) {
    except = e;
    }

    if (except == null)
    return 42;
    else
    throw except;
    }

... but that would be Vile Beyond Belief.

Signature

Eric.Sosman@sun.com

Reply to this Message

Patricia Shanahan - 18 Jun 2005 02:11 GMT

>> If I have a method, is it better to write it so it has a single exit
>> point and is (marginally) more complicated or so it has more than one
[quoted text clipped - 6 lines]
> one that is most readable and clearly. Having a single exit point is
> often better, but not always (despite what the zealots will tell you).

One of the strongest arguments I've seen for single exit, the difficulty
of inserting clean-up code in a multi-exit procedure, does not apply to
Java because of try-finally.

Patricia

Reply to this Message

> If I have a method, is it better to write it so it has a single exit point and
> is (marginally) more complicated or so it has more than one exit point eg:
[quoted text clipped - 20 lines]
> }
> }

Neither is better:

public int crap(int data){

return (data > 0 ? data : -1);
}

Greetings, Leon.

Reply to this Message

simple coding style question

Free Magazines