Break and Return Statements

[Anony!]

Hi

I realize that using breaks in code is not recommended and should be
avoided. However, I have a situation where it cannot be avoided.

<snippet>
public String aMethod()
{
for (...)
{
if (...)
{
//some processing 1
break;
}
if (...)
{
//some processing 2
}
}
return result;
}

I tried to put the return statement where the break statement is hoping that
it would terminate further processing and return the result. But the compile
complains that nothing is returned. That makes sense because the return
statement needs to be at the end. Therefore I have to make use of the break
to get out of the loop and then return the result.

AaA

 

[David Hilsee]

Hi

I realize that using breaks in code is not recommended and should be
avoided. However, I have a situation where it cannot be avoided.

<snippet>
public String aMethod()
{
for (...)
{
if (...)
{
//some processing 1
break;
}
if (...)
{
//some processing 2
}
}
return result;
}

Don't sweat it. There are certain people who believe that break should
never be used, but I've never bought it, and, in my experience, it rarely
causes a maintenance issue. If you really want to avoid using break, use a
boolean value that is checked in the for loop and will be used to terminate
it. I can virtually guarantee that you can restructure the code to use such
a boolean value.

 

[Vincent Cantin]

Hi
Why ? I don't see any good reason to not use it. The boolean approch makes
the functions harder to read and longer to write.

 

[Chris Smith]

Why ? I don't see any good reason to not use it. The boolean approch makes
the functions harder to read and longer to write.

It's a rather old rule, and it was invented to apply to people using
goto and such in an ad hoc manner. Essentially the rule goes that each
structured control block in code should have exactly one entrance point
and exactly one exit point. If this rule is followed, it effectively
prevents the worst of spaghetti code. Since all looping constructs come
with their own condition, the corrolary is that using a break statement
is bad.

I think consensus has been reached in most places that many "thou shalt
not" kinds of rules in software development are not a good idea. In
practice, what matters is making sure that your code can be understood
by the person reading it. A bunch of random break statements all over
the place can be confusing. A single break at an obvious location, or a
lot of breaks in an obvious pattern, generally isn't.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[David Hilsee]

It's a rather old rule, and it was invented to apply to people using
goto and such in an ad hoc manner. Essentially the rule goes that each
structured control block in code should have exactly one entrance point
and exactly one exit point. If this rule is followed, it effectively
prevents the worst of spaghetti code. Since all looping constructs come
with their own condition, the corrolary is that using a break statement
is bad.

I think consensus has been reached in most places that many "thou shalt
not" kinds of rules in software development are not a good idea. In
practice, what matters is making sure that your code can be understood
by the person reading it. A bunch of random break statements all over
the place can be confusing. A single break at an obvious location, or a
lot of breaks in an obvious pattern, generally isn't.

Exactly. Even the "abhorrent" goto, which is now shunned by nearly
everyone, can actually improve readability in certain situations ("Code
Complete" contains some good examples). I believe that all software
development "thou shalt not" rules have exceptions (even this one ;-)) that
must be considered before blindly applying the rule, and that was what I was
trying to convey in my original response.

 

[Larry Coon]

I realize that using breaks in code is not recommended and should be
avoided.

Others have already commented on this, so I won't bother.

However, I have a situation where it cannot be avoided.

<snippet>
public String aMethod()
{
for (...)
{
if (...)
{
//some processing 1
break;
}
if (...)
{
//some processing 2
}
}
return result;
}

I tried to put the return statement where the break statement is hoping that
it would terminate further processing and return the result. But the compile
complains that nothing is returned.

Your function is declared with a String return value. All
return statements must therefore return Strings. It sounds
like you put in something like:
return;
and not:
return someString;

That makes sense because the return
statement needs to be at the end.

Not correct. Returns can go anywhere. As Chris said, one
line of thinking says a block of code should have one way
in and one way out. But that's not a syntactic requirement.


Larry Coon
University of California

 

[Woebegone]

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.733 / Virus Database: 487 - Release Date: 02/08/04

 

[Steve Horsley]

Not correct. Returns can go anywhere. As Chris said, one
line of thinking says a block of code should have one way
in and one way out. But that's not a syntactic requirement.

What's more, I think (IMHO) that a return in the middle of a
loop (or nested loops) is generally easier to understand than a
convoluted arrangements of breaks, flags or a labelled break.

Steve.

 

[Anony!]

What's more, I think (IMHO) that a return in the middle of a
loop (or nested loops) is generally easier to understand than a
convoluted arrangements of breaks, flags or a labelled break.

Steve.

a return in a middle of a loop doesnt "break" out of it. otherwise the
compiler would not be complaining that i havent returned anything.

 

[Brian Palmer]

a return in a middle of a loop doesnt "break" out of it. otherwise the
compiler would not be complaining that i havent returned anything.

It does. But when considering a loop's effect on a program, you have
to think about what would happen if it never ran. For example,

boolean f () {
while (false) {
return true;
}
}

clearly has the chance that it will get to the end of the function
without returning. You've got to make sure you cover every path
through the function with a return statement. In some cases, you will
"know" that there will always be a return statement called:

if (condition1) { return 2; }
else if (condition2) { return 3}
else if (condition3) { return 4; }

where the conditions span all possibilities... but the compiler won't
know that.