Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

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

OUTERLOOP: for ( ;/*stuff*/; ) {     //...lots of code      if ( isEnough() ) break OUTERLOOP;     //...more code } 

I was wondering what the common convention for the labels was. All caps? first cap?

like image 983
Mo. Avatar asked Aug 19 '08 01:08

Mo.


People also ask

Which is the correct naming convention for Java method?

Interface names should be capitalized like class names. Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized. Except for variables, all instance, class, and class constants are in mixed case with a lowercase first letter.

What is the naming conventions of label?

A label should have an uppercase first letter and all the other internal words should begins with lowercase. Labels should not end with a period unless they end with three periods, for example: “New…”, “Add…”. You should not use text constants (for example “%1 - %2”) to format labels.

What is the standard class naming convention in Java?

In Java, class names generally should be nouns, in title case with the first letter of each separate word capitalized. and interface names generally should be adjectives, in title case with the first letter of each separate word capitalized.


1 Answers

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.

like image 116
Marcus Downing Avatar answered Oct 04 '22 13:10

Marcus Downing