Without break? How can manage to do that?

[Wilson Yang]

The Java programming style posted on this site stated that 'break' are prohibited unless it is in a 'switch'...
But I've been using it massively in my code, what can I do to replace all those goofy 'break's?

Thanks a lot...

[Jesper de Jong]

Welcome to JavaRanch.

Can you show us an example of one of your "goofy breaks"? Here's an example of using 'break' in a for-loop and how you could change it. Note that programming style is often a matter of personal preference and should be used as a general guide, not as an unbreakable law. In the example below, I'm not sure if avoiding 'break' is a good idea - it doesn't really make the code more clear.

List<String> names = ...;
 
// For-loop with break
boolean found = false;
for (String name : names) {
    if (name.equals("Jesper")) {
        found = true;
        break;
    }
}
 
// Rewritten without break - note that we can't use the new for-loop syntax now
boolean found = false;
for (Iterator<String> i = names.iterator(); i.hasNext() && !found; ) {
    String name = i.next();
    if (name.equals("Jesper")) {
        found = true;
    }
}

[ May 07, 2008: Message edited by: Jesper Young ]

[Wilson Yang]

that's exactly what i was saying, thank you for your fast response...
(As a beginner, I really don't know how much i should stick to those programming style). Anyway, Is there anyone who really writes all his code in that way?

[Ernest Friedman-Hill]

Originally posted by Wilson Yang:
that's exactly what i was saying, thank you for your fast response...
(As a beginner, I really don't know how much i should stick to those programming style). Anyway, Is there anyone who really writes all his code in that way?

The style guide on this site is intended for the folks in the Cattle Drive (our Java programming course.) The style is a little peculiar, but one of the main reasons for its existence is to teach folks to write code to meet a style guide, whether you agree with it or not. If that's what your employer asks you to do, then that's what you'll have to do.

[Campbell Ritchie]

The reluctance to use "break" like that is to fulfill the conventions of an older programming paradigm, structured programming. This emanates from a paper by Bohm and Jacopini in 1966 where they demonstrated that every program can be implemented with a combination of

sequence

iteration (or, as apparently shown by Alan Turing in the 1930s, recursion), and

selection.

A "break" in the middle of a loop breaks the integrity of the iteration and is therefore incompatible with structured programming.

There are different opinions about how strictly one should adhere to structured programming; I think it is best learning to follow it strictly is the best training.

[Jim Yingst]

Yep. Learn to follow it strictly, for the learning experience. Then ignore it after that.

Nah, I exaggerate. But I'm one of those who believes that break, and embedded returns, and sometimes even continue, can lead to simpler, cleaner code. Sometimes. So unless I'm on a job where there's a coding standard that prohibits it, I would merrily use a break in an example like the one Jesper posted. Well, in that case I'd probably write it with a return statement instead, but same general idea:

boolean findJesper() {
    for (String name : names)
        if (name.equals("Jesper"))
            return true;
    return false;
}

Well in this case, the contains() method would also work, but that's beside the point. Multiple returns like this are also considered unstructured, and therefore bad, according to some people. To me, they seem like the most straightforward way to code something like this. Either way, it's important to be able to understand each of these styles when you see it, and also to be able to write your code in a particular style, when required to.

[Bill Shirley]

To summarize: You should always avoid break, except when you shouldn't.

I've seen breaks misused far more often than I've seen the lack of breaks hamper readability. And this is likely the reason for flat out rules in larger environments. It's easier to espouse "Just Say No" (ask Nancy Reagan) than to elucidate a reasonable but detailed stance on a complex topic.

[Jim Yingst]

No it isn't.

[Jim Yingst]

[Pat Farrell]

Originally posted by Campbell Ritchie:
an older programming paradigm, structured programming.

Of course, that concept, structured programming, was out of date/favor by the 90s, so its so last century.

Java is an OO language, its much better than that old structured stuff. :-)

All rules are false, including this one.

[Jesper de Jong]

Originally posted by Campbell Ritchie:
The reluctance to use "break" like that is to fulfill the conventions of an older programming paradigm, structured programming...

The reason why 'break' is considered bad is because it can be regarded as a disguised goto statement, which could make your code an unreadable mess quickly if you use it too often.

[Ilja Preuss]

Originally posted by Jim Yingst:
Well, in that case I'd probably write it with a return statement instead, but same general idea:

I find the return statement to be more readable, because it's easier to reason about where the program flow will continue when it gets executed.

Also, it forces me to write smaller methods, which is A Good Thing (TM).

[Jim Yingst]

Agreed, that's why I favor return over break. And with short methods, other concerns about readability (for return/break/continue) tend to go away too; it's a non-issue.
[ May 09, 2008: Message edited by: Jim Yingst ]