Why it is a bad practice to use break/continue labels in OOP (e.g. Java, C#)?

Question

I was told that using break and continue labels in an OOP language is not OOP programming style. Can you explain in detail why and what is the problem?

The trick was with this label word. I meant labeled break/continue.

class BreakWithLabelDemo {
    public static void main(String[] args) {

        int[][] arrayOfInts = {
            { 32, 87, 3, 589 },
            { 12, 1076, 2000, 8 },
            { 622, 127, 77, 955 }
        };
        int searchfor = 12;

        int i;
        int j = 0;
        boolean foundIt = false;

    search:
        for (i = 0; i < arrayOfInts.length; i++) {
            for (j = 0; j < arrayOfInts[i].length;
                 j++) {
                if (arrayOfInts[i][j] == searchfor) {
                    foundIt = true;
                    break search;
                }
            }
        }

        if (foundIt) {
            System.out.println("Found " + searchfor +
                               " at " + i + ", " + j);
        } else {
            System.out.println(searchfor +
                               " not in the array");
        }
    }
}

http://docs.oracle.com/javase/tutorial/java/nutsandbolts/branch.html

Was this in context to some specific code block or a general comment ? [One who faced the same](http://programmers.stackexchange.com/questions/58237/are-break-and-continue-bad-programming-practices) — V4Vendetta, Jun 21 '12 at 07:08
http://programmers.stackexchange.com/questions/58237/are-break-and-continue-bad-programming-practices — Niko, Jun 21 '12 at 07:10
@Int3ὰ: I'll expand on your statement and say that you should be skeptic on _everything_. But be careful: This makes you think about everything and discover a huge tonnage of logical fallacies in human in general. Being skeptic is the red pill of life. — Sebastian Mach, Jul 28 '14 at 20:34
@phresnel thanks for the comment. I understand what you mean. Let me tell you one thing, software engineering is not about following best practice **always**, trust me people hate when I use static variables as they believe it makes code hard to read, maintain and debug or whatever but it has its own purpose. Have you every gone through the android source code? you find is full of mess , that does not mean it does not work. In fact people love it. People tries to avoid reflection as much as they think it degrades performance, and yes it clearly does ..... contd — crypted, Jul 29 '14 at 05:07
@phresnel, But it is really important to understand what is performance. Latest framework like Caliburn micro, DI containers use reflection at the fullest.And I have never found any performance limitation using these frameworks. I just tend to use something that best fits for the situation. And I repeat same thing, **Don't trust everything you hear** — crypted, Jul 29 '14 at 05:14
@Int3ὰ: I am just more extremist in being skeptic :P I haven't seen Android sources, but I find the vanilla Java API a mess for small-scale applications already. For months already I am researching better environments for developing Android applications than the vanilla API. The API is structured and all, however, it is, imho, way too much for what are basically Hello-World apps in many cases :) — Sebastian Mach, Jul 29 '14 at 08:43

score 26 · Accepted Answer · answered Jun 21 '12 at 07:22

26

The person who told you that would probably means that break and continue are branching statements like goto which are one mechanism of imperative programming.

A break/continue only allow you to jump to an outer statement, which means that you cannot go everywhere in the code. So you stay in the same method object, so it's not incompatible with OOP.

Anyway, saying that break and continue are not OOP is a non-sense. We can discuss about their impact on the readibility maybe but that's all.

answered Jun 21 '12 at 07:22

tibo

5,326
4
37
53

This is not a great answer, using continue in particular means that the internal of a loop is now controlling the outer loop functionality itself, this not only buggers up readability but breaks the solid principles. Also now it means you are obviously looping through elements that are not required. You shouldn't use continue as the condition specified for the continue should be on the list you are looping in the loop instruction. also when you update the object used in the list you may have to change not only the loop itself, but know about and find the continue if statement. – Slipoch Mar 30 '22 at 22:49

score 21 · Answer 2 · edited Mar 14 '15 at 18:09

break and continue are not functional style programming. There is nothing about OOP which suggestsbreak, continue or even goto within a method is a bad idea.

IMHO using break and continue are discouraged in OOP languages as they can lead to complexity and confusion. As Labels are used rarely they can confuse even further. I would say you should still use them when you feel its the simplest solution to the problem.

// confusing use of LABEL
http://www.google.com/
do {
    if (condition) continue http;
} while(condition2)

another confusing use

GOTO: {
    // code
    if (condition)
         break GOTO; // without a loop
    // code
}

Good use of a label

OUTER: 
for(outer loop) {
   for(inner loop)
      if (condition)
         continue or break OUTER;
}

Odd use of a label

FOUND: {
   for(loop)
      if(found)
          break FOUND;

   // not found
   handle not found
}

I disagree on the goto, if goto let's you go anywhere in the code it is no more OOP. If goto is limited to the current method, then ok. — tibo, Jun 21 '12 at 07:25

score 8 · Answer 3 · answered Jun 21 '12 at 08:35

8

The advice not to use break/continue is probably not really related to OOP. It is based on the fact that these statements are similar to the infamous GOTO, which can make code completely unreadable. However, dogmas are bad counsels. The main paradigm should be readability of the code. Jumping out of a loop in the first line using break or continue can be much clearer than putting the whole rest into an if condition.

answered Jun 21 '12 at 08:35

Heiko Schmitz

300
1
4

Exactly, this is my point. Right now my loop with a continue is readable but our linter is complaining. Sigh... break, continue are nothing like GOTO and necessary in lots of cases. – Gaston Sanchez Jan 28 '16 at 00:28
If you use continue then it means your loop elements are not restricted enough, so there is the potential you are looping through unnecessary elements. It also means that at any point inside a loop, you break the 'rules' of the loop. So any change at a later date may break things if you do not notice a continue. – Slipoch Mar 30 '22 at 22:40

score 3 · Answer 4 · answered Jun 21 '12 at 07:15

Bruce Eckel wrote in "Thinking in Java" following idea: "It’s important to remember that the only reason to use labels in Java is when you have nested loops and you want to break or continue through more than one nested level."

Actually when you don't use lables the workflow of code is more clear in many cases.

score -3 · Answer 5 · answered Jun 21 '12 at 07:14

-3

I think main reason is that code is not so clear with break and continue.

But also may be some performance issues (not related to OOP): CPU use predictors to load instruction in queue before this instruction will be processed. It easy for predictor to detect what instructions to load next for conditional jump and will be harder for unconditional.

answered Jun 21 '12 at 07:14

alexey28

5,170
1
20
25

1

You're saying that CPU branch predictors can't handle unconditional jumps? It's been quite a few years since I was dealing with hardware at that level, but at the time the unconditional jump was considered to be the _trivial_ case… – Donal Fellows Jun 21 '12 at 09:10
I think the OP confused his statement with compiler optimizations. From code complete: An unconditional goto makes the flow harder to analyze and reduces the ability of the compiler to optimize the code. – rents Mar 30 '17 at 19:02

Why it is a bad practice to use break/continue labels in OOP (e.g. Java, C#)?

5 Answers5

Linked