Java Coding standard / best practices - naming convention for break/continue labels

Question

Sometimes a labeled break or continue can make code a lot more readable.

OUTERLOOP: for ( ;/*stuff*/; ) {
    //...lots of code

    if ( isEnough() ) break         


        

Answer 1

wrt sadie's code example:

You gave

outerloop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outerloop;
    //  more code
  }
  //  more code
}

As an example. You make a good point. My best guess would be:

public void lookMumNoLabels() {
  for (...) {
    // some code
    doMoreInnerCodeLogic(...);
  }
}

private void doMoreInnerCodeLogic(...) {
   for (...) {
      // some code
      if (...) return;
   }
}

But there would be examples where that kind of refactoring doesn't sit correctly with whatever logic you're doing.

Answer 2

If you have to use them use capitals, this draws attention to them and singles them out from being mistakenly interpreted as "Class" names. Drawing attention to them has the additional benefit of catching someone's eye that will come along and refactor your code and remove them. ;)

Answer 3

Sun's Java code style seem to prefer naming labels in the same way as variables, meaning camel case with the first letter in lower case.

Answer 4

As labels are so rarely useful, it appears, that there is no clear convention. The Java language specification has one example with labels and they are in non_cap.

But since they are so rare, in my opinion it is best, to think twice whether they are really the right tool.

And if they are the right tool, make them all caps so that other developers (or yourself later on) realize them as something unusual right away. (as Craig already pointed out)

Answer 5

I know, I should not use labels.

But just assume, I have some code, that could gain a lot in readability from labeled breaks, how do I format them.

Mo, your premise is wrong. The question shouldn't be 'how do I format them?'

Your question should be 'I have code that has a large amount of logic inside loops - how do I make it more readable?'

The answer to that question is to move the code into individual, well named functions. Then you don't need to label the breaks at all.

Answer 6

I don't understand where this "don't use labels" rule comes from. When doing non-trivial looping logic, the test to break or continue isn't always neatly at the end of the surrounding block.

outer_loop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outer_loop;
    //  more code
  }
  //  more code
}

Yes, cases like this do happen all the time. What are people suggesting I use instead? A boolean condition like this?

for (...) {
  //  some code
  boolean continueOuterLoop = false;
  for (...) {
    //  some code
    if (...) {
      continueOuterLoop = true;
      break;
    }
    //  more code
  }
  if (continueOuterLoop)
    continue;
  //  more code
}

Yuck! Refactoring it as a method doesn't alleviate that either:

boolean innerLoop (...) {
  for (...) {
    //  some code
    if (...) {
      return true;
    }
    //  more code
  }
  return false;
}

for (...) {
  //  some code
  if (innerLoop(...))
    continue;
  //  more code
}

Sure it's a little prettier, but it's still passing around a superfluous boolean. And if the inner loop modified local variables, refactoring it into a method isn't always the correct solution.

So why are you all against labels? Give me some solid reasons, and practical alternatives for the above case.