Develop Reference

Is there a name for the difference of these two code styles?

When i see code from others, i mainly see two types of method-styling.
One looks like this, having many nested ifs:
void doSomething(Thing thing) {
if (thing.hasOwner()) {
Entity owner = thing.getOwner();
if (owner instanceof Human) {
Human humanOwner = (Human) owner;
if (humanOwner.getAge() > 20) {
//...
}
}
}
}
And the other style, looks like this:
void doSomething(Thing thing) {
if (!thing.hasOwner()) {
return;
}
Entity owner = thing.getOwner();
if (!(owner instanceof Human)) {
return;
}
Human humanOwner = (Human) owner;
if (humanOwner.getAge() <= 20) {
return;
}
//...
}
My question is, are there names for these two code styles? And if, what are they called.

The early-returns in the second example are known as guard clauses.
Prior to the actual thing the method is going to do, some preconditions are checked, and if they fail, the method immediately returns. It is a kind of fail-fast mechanism.
There's a lot of debate around those return statements. Some think that it's bad to have multiple return statements within a method. Others think that it avoids wrapping your code in a bunch of if statements, like in the first example.
My own humble option is in line with this post: minimize the number of returns, but use them if they enhance readability.
Related:
Should a function have only one return statement?
Better Java syntax: return early or late?
Guard clauses may be all you need

I don't know if there is a recognized name for the two styles, but in structured programming terms, they can be described as "single exit" versus "multiple exit" control structures. (This also includes continue and break statements in loop constructs.)
The classical structured programming paradigm advocated single exit over multiple exit, but most programmers these days are happy with either style, depending on the context. Even classically, relaxation of the "single exit" rule was acceptable when the resulting code was more readable.
(One needs to remember that structured programming was a viewed as the antidote to "spaghetti" programming, particularly in assembly language, where the sole control constructs were conditional and non-conditional branches.)

i would say it's about readability. The 2nd style which i prefer, gives you the opportunity to send for example messages to the user/program for any check that should stop the program.

One could call it "multiple returns" and "single return". But I wouldn't call it a style, you may want to use both approaches, depending on readability in any particular case.
Single return is considered a better practice in general, since it allows you to write more readable code with the least surprise for the reader. In a complex method, it may be quite complicated to understand at which point the program will exit for any particular arguments, and what side effects may occur.
But if in any particular case you feel multiple returns improve readability of your code, there's nothing wrong with using them.

Java comment at end of brace/block

Is it an accepted practice in the Java programming language to end a brace for a code block with a comment that briefly explains what code block the brace closes off? I personally would think that they are useless comments that clutter the readability of the code, but perhaps I could be wrong. For example:
public void myMethod(int foo) {
// some code
if (foo == 2) {
for (int i = 0; i < myMax; i++) {
while (true) {
// some more code
} // end while
} // end for
} // end if
} // end myMethod(int)
Is the practice of commenting code blocks in a similar manner an accepted practice?

My take on it is that as a rule it is NOT a good practice. As always with rules there could be exceptions but very rare.
It is not a good practice because
Modern editors highlight the opening bracket when you place cursor on the closing one and vice versa.
Most important: if there is a possibility to not see the beginning of the clause it means that the method is huge (more than half a page) which is a bad practice.
It adds noise to the code that will confuse readers who are used to more conventional Java coding style.
Incorporating LordScree-Joachim Sauer comment: These comments will
be pain in the neck to maintain. So most likely it will not be maintained and the information will usually be out of sync with reality.

This is not exactly a bad practice, BUT it is a deadly side effect of poor Object-Oriented coding practice!
Also, this violates style guidelines and the tenets of "self-documenting code". You should never have that many brackets or a method long enough to confuse the reader about bracket placement, instead encapsulate that functionality in another method that is well documented.
Brackets imply either looping or complex if-else logic chains, good programming practice is to have a method do exactly one thing and do it well, then build your program from these smaller, atomized methods. I would read Butler Lampson's seminal piece "Hints for Computer System Design". It goes into some of the details on how to design good software.
So essentially, don't comment like this because:
It violates style guidelines
It shows poor Object-Oriented programming - atomize your functionality!
It is a deadly side effect of coding practice which goes against the underlying concepts of why Java was created - encapsulation, specifically information hiding
It violates the concept of self-documenting code
Other programmers will make fun of you.

I only do this when there is a place in code that has a lot of closing braces after each other. But not for every brace. Mainly I seem to use it for loops so that you can easly see what is a repeated code block.
Something that looks like this:
// ...
file.Close();
}
}
}
}
}
}
Then it helps to add some comments:
// ...
file.Close();
}
}
}
}//for: each file
}
}

It depends on how complicated the method or function is. Like if you have something that can be easily read and understood than there really wouldn't be a point in ending EVERY line with a comment that explains that the part has ended. That's what indentation and line breaks are for. However if you have something that is truly complex and affects a major part of your code then you should denote where that code ends and what that section does.

If there are nested blocks of same kind, it may be confusing instead of doing good. Let's say you have 4 or 5 nested if statements(keep in mind that this only an example to demonstrate the situation, regardless of "oh you should separate those" or "make a method" suggestions) in that case you will have 4 or 5 different //end if sequenced. After a while, it makes you confuse which "end if" is for which statement, makes you spend extra effort unconsciously to see through the actual code/statements because it's not always as clean/short as your example.

IMO, It does not help much. The code inside a loop or an if statement should not be too big.
It would have helped if there were 500 lines inside the loop.

Why does code with successive semi-colons compile?

According to my scientific Java experimentation, int x = 0; is equivalent to int x = 0;; which is equivalent to int x = 0;;;;;;;;;;;;;;;
Why does Java allow for this? Does it have any practical application?
Are each of these just empty statements? Do they actually take up any extra processing time during runtime? (I would assume they're just optimized out?)
Do other languages do this? I'm guessing it's something inherited from C, like a lot of things in Java. Is this true?

The extra semicolons are treated as empty statements. Empty statements do nothing, so that's why Java doesn't complain about it.

As Jake King writes, you can produce empty statements to do nothing in a loop:
while (condition);
but to make it obvious, you would write
while (condition)
;
or even better:
while (condition)
/** intentionally empty */
;
or even better, as Michael Kjörling pointed out in the comment,
while (condition)
{
/** intentionally empty */
}
More often, you see it in for-statements for endless loops:
for (;;)
or only one empty statement
for (start;;)
for (;cond;)
for (;;end)
Another thing you can do, is, to write a program, once with one, and once with 2 semicolons:
public class Empty
{
public static void main (String args[])
{
System.out.println ("Just semicolons");;
}
}
Compile it, and run list the size of byte code (identic) and do an md5sum on the bytecode (identic).
So in cases, where the semantics aren't changed, it is clearly optimized away, at least for the 1.6-Oracle compiler I can say so.

Yes, they are empty statements, which don't do anything at all. They are optimized out by the compiler, but in some cases this empty statement actually does something, doing the same thing as a set of empty braces ({}). They are inherited from C syntax, but they have few uses in Java. In C, sometimes doing something like this was useful:
while (condition);
This will loop until condition is false, preventing code from progressing. However, this is discouraged in modern code, and shouldn't ever really be used in Java. However, the empty statement does count as a statement, just a useless one, so constructs like this:
if (condition);
doSomething();
....may cause somewhat baffling results. The if statement will call the empty statement, not the method, so the method will always be called. Just a caveat to keep in mind.

One thing to note is that if you do something like this:
public int foo()
{
return(0);;
}
The compiler will/may complain about an unreachable statement because there's an empty statement after a return. At least with Oracle's 1.6 sdk it does.

Java what is the double underscore notation for?

I was browsing the web and found this example. Within the public static void main method is this line syntax which I have never seen before __main:
As in:
public class Klass {
public static void main(String[] args) {
// code goes here...
__main:
// and mode code here...
}
}
I tried punching this into eclipse and got a little yellow underline with a tool-tip which said "The label __main is never explicitly referenced".
I can't find anything online and I'm really curious! I've been programming in Java for years and I've never seen this syntax before. What does it do, why would you use it, where can I learn more?

That's a label. You can use it with the break and continue statements. It's not necessary, to use the double underscore.
To be more precise: it is (the first) part of a Labeled Statement (JLS 14.7):
Identifier : Statement

Double underscores in Java have not semantic meaning (the same way that single underscores don't have any semantic meaning).
The only meaning they could have would depend on some naming convention that defines what they are used for.
It looks like the code you look at uses double underscores for labels. Since labels are not frequently used in Java, I wouldn't worry to much about it.

A goto statement in C and its counterparts are accompanied by a Label argument. In a defined method, a goto label; statement will fire the routine proceeding the label. Below is an example demonstrated by Greg Rogers in this Post.
void foo()
{
if (!doA())
goto exit;
if (!doB())
goto cleanupA;
if (!doC())
goto cleanupB;
// everything succeed
return;
cleanupB:
undoB();
cleanupA:
undoA();
exit:
return;
}
A goto can be a very effective tool in Java, but Java does not explicitly support the goto keyword even though the keyword has been reserved by the language. Using a break statement will enable the command jump out of the label to proceed to the statement after the label.
Example:
public class Klass {
public static void main(String[] args) {
// code goes here...
__main:
{
if(args.length==0)
{
break __main;
}
}
//code after label
}
}
The package com.sun.org.apache.bcel.internal.generic.GOTO, I have not used it personally but I think it can aid to achieve the same code structure as demonstrated by Greg Rogers like this:
void foo()
{
if (!doA())
GOTO exit;
if (!doB())
GOTO cleanupA;
if (!doC())
GOTO cleanupB;
// everything succeed
return;
cleanupB:
undoB();
cleanupA:
undoA();
exit:
return;
}
void undoB(){}
void undoA(){}
boolean doC(){return false;}
boolean doA(){return false;}
boolean doB(){return false;}

The double underscores are irrelevant. You are really asking about Labels. Here is some info . Basically they are used for controling breaks. Also a fun trivia question in interviews: Does the following code compile?
public void doSomething(){
http://www.stackoverflow.com
}
Why yes it does and now you know why:D

Java has labels (but no goto). The double underscore has no meaning but it is a legal Java identifier.
From the JLS:
14.7 Labeled Statements Statements may have label prefixes.
LabeledStatement:
Identifier : Statement
LabeledStatementNoShortIf:
Identifier : StatementNoShortIf
The Identifier is declared to be the label of the immediately
contained Statement.
Unlike C and C++, the Java programming language has no goto statement;
identifier statement labels are used with break (§14.14) or continue
(§14.15) statements appearing anywhere within the labeled statement.
The scope of a label declared by a labeled statement is the statement
immediately enclosed by the labeled statement.

It's just a label. you could write bla:, for the same effect.
Labels are generally used with goto statements, but as far as I know, goto is forbidden in java (and greatly discouraged in any other high-level language).
This can also, however, be used inside loops with continue and break, e.g. continue someLabel;, if you want the continue or the break to refer to an outer loop rather than the immediate one you are in right now.

double underscore and labels tend to be used more in C. Perhaps the developer have been writing C recently.
BTW: Labels are rarely used for loops but an even rarer use is to jump out of scope.
scope: {
// some code
if (flag)
break scope; // no loop
// some more code
}
Because labels are rare, they can more confusing than useful. ;)

Nobody seems to have answered EXACTLY what you actually asked (but the "goto" answers are probably what you were really looking for) and they are right about it just being an identifier, but not why they were used in this case.
The double-underscore is typically used within the system to prevent possible collisions with other identifiers... usually it is used in cases where the scope is available to the user. In this case without the underscores you might be prevented from making a "main" variable at some point or another, or perhaps some system-class would be prevented from using the word main.
In this case I'm guessing that if the variable had been named "main" it would conflict with the "public static void main" being defined.
I guess in summary the double-underscore is a form of manual scoping..

Should I avoid using Java Label Statements?

Today I had a coworker suggest I refactor my code to use a label statement to control flow through 2 nested for loops I had created. I've never used them before because personally I think they decrease the readability of a program. I am willing to change my mind about using them if the argument is solid enough however. What are people's opinions on label statements?

Many algorithms are expressed more easily if you can jump across two loops (or a loop containing a switch statement). Don't feel bad about it. On the other hand, it may indicate an overly complex solution. So stand back and look at the problem.
Some people prefer a "single entry, single exit" approach to all loops. That is to say avoiding break (and continue) and early return for loops altogether. This may result in some duplicate code.
What I would strongly avoid doing is introducing auxilary variables. Hiding control-flow within state adds to confusion.
Splitting labeled loops into two methods may well be difficult. Exceptions are probably too heavyweight. Try a single entry, single exit approach.

Labels are like goto's: Use them sparingly, and only when they make your code faster and more importantly, more understandable,
e.g., If you are in big loops six levels deep and you encounter a condition that makes the rest of the loop pointless to complete, there's no sense in having 6 extra trap doors in your condition statements to exit out the loop early.
Labels (and goto's) aren't evil, it's just that sometimes people use them in bad ways. Most of the time we are actually trying to write our code so it is understandable for you and the next programmer who comes along. Making it uber-fast is a secondary concern (be wary of premature optimization).
When Labels (and goto's) are misused they make the code less readable, which causes grief for you and the next developer. The compiler doesn't care.

There are few occasions when you need labels and they can be confusing because they are rarely used. However if you need to use one then use one.
BTW: this compiles and runs.
class MyFirstJavaProg {
public static void main(String args[]) {
http://www.javacoffeebreak.com/java101/java101.html
System.out.println("Hello World!");
}
}

I'm curious to hear what your alternative to labels is. I think this is pretty much going to boil down to the argument of "return as early as possible" vs. "use a variable to hold the return value, and only return at the end."
Labels are pretty standard when you have nested loops. The only way they really decrease readability is when another developer has never seen them before and doesn't understand what they mean.

I have use a Java labeled loop for an implementation of a Sieve method to find prime numbers (done for one of the project Euler math problems) which made it 10x faster compared to nested loops. Eg if(certain condition) go back to outer loop.
private static void testByFactoring() {
primes: for (int ctr = 0; ctr < m_toFactor.length; ctr++) {
int toTest = m_toFactor[ctr];
for (int ctr2 = 0; ctr2 < m_divisors.length; ctr2++) {
// max (int) Math.sqrt(m_numberToTest) + 1 iterations
if (toTest != m_divisors[ctr2]
&& toTest % m_divisors[ctr2] == 0) {
continue primes;
}
} // end of the divisor loop
} // end of primes loop
} // method
I asked a C++ programmer how bad labeled loops are, he said he would use them sparingly, but they can occasionally come in handy. For example, if you have 3 nested loops and for certain conditions you want to go back to the outermost loop.
So they have their uses, it depends on the problem you were trying to solve.

I've never seen labels used "in the wild" in Java code. If you really want to break across nested loops, see if you can refactor your method so that an early return statement does what you want.
Technically, I guess there's not much difference between an early return and a label. Practically, though, almost every Java developer has seen an early return and knows what it does. I'd guess many developers would at least be surprised by a label, and probably be confused.
I was taught the single entry / single exit orthodoxy in school, but I've since come to appreciate early return statements and breaking out of loops as a way to simplify code and make it clearer.

I'd argue in favour of them in some locations, I found them particularly useful in this example:
nextItem: for(CartItem item : user.getCart()) {
nextCondition : for(PurchaseCondition cond : item.getConditions()) {
if(!cond.check())
continue nextItem;
else
continue nextCondition;
}
purchasedItems.add(item);
}

I think with the new for-each loop, the label can be really clear.
For example:
sentence: for(Sentence sentence: paragraph) {
for(String word: sentence) {
// do something
if(isDone()) {
continue sentence;
}
}
}
I think that looks really clear by having your label the same as your variable in the new for-each. In fact, maybe Java should be evil and add implicit labels for-each variables heh

I never use labels in my code. I prefer to create a guard and initialize it to null or other unusual value. This guard is often a result object. I haven't seen any of my coworkers using labels, nor found any in our repository. It really depends on your style of coding. In my opinion using labels would decrease the readability as it's not a common construct and usually it's not used in Java.

Yes, you should avoid using label unless there's a specific reason to use them (the example of it simplifying implementation of an algorithm is pertinent). In such a case I would advise adding sufficient comments or other documentation to explain the reasoning behind it so that someone doesn't come along later and mangle it out of some notion of "improving the code" or "getting rid of code smell" or some other potentially BS excuse.
I would equate this sort of question with deciding when one should or shouldn't use the ternary if. The chief rationale being that it can impede readability and unless the programmer is very careful to name things in a reasonable way then use of conventions such as labels might make things a lot worse. Suppose the example using 'nextCondition' and 'nextItem' had used 'loop1' and 'loop2' for his label names.
Personally labels are one of those features that don't make a lot of sense to me, outside of Assembly or BASIC and other similarly limited languages. Java has plenty of more conventional/regular loop and control constructs.

I found labels to be sometimes useful in tests, to separate the usual setup, excercise and verify phases and group related statements. For example, using the BDD terminology:
#Test
public void should_Clear_Cached_Element() throws Exception {
given: {
elementStream = defaultStream();
elementStream.readElement();
Assume.assumeNotNull(elementStream.lastRead());
}
when:
elementStream.clearLast();
then:
assertThat(elementStream.lastRead()).isEmpty();
}
Your formatting choices may vary but the core idea is that labels, in this case, provide a noticeable distinction between the logical sections comprising your test, better than comments can. I think the Spock library just builds on this very feature to declare its test phases.

Personally whenever I need to use nested loops with the innermost one having to break out of all the parent loops, I just write everything in a method with a return statement when my condition is met, it's far more readable and logical.
Example Using method:
private static boolean exists(int[][] array, int searchFor) {
for (int[] nums : array) {
for (int num : nums) {
if (num == searchFor) {
return true;
}
}
}
return false;
}
Example Using label (less readable imo):
boolean exists = false;
existenceLoop:
for (int[] nums : array) {
for (int num : nums) {
if (num == searchFor) {
exists = true;
break existenceLoop;
}
}
}
return exists;