Android standard brace style legality

Reading this piece of information, it states that:

We require braces around the statements for a conditional. Except, if the entire conditional (the condition and the body) fit on one line, you may (but are not obligated to) put it all on one line. That is, this is legal:

if (condition) {
    body(); 
}

and this is legal:

if (condition) body();

but this is still illegal:

if (condition)
    body();  // bad!

Why is the last mentioned bad? It is a mix of the two above, but what is the motivation for not using that kind of style? IMO, it is the most readable (or equaly readable to the firs开发者_JAVA技巧t one).

I know that may not apply to Android specifically, but it's the first place I've heard about it.

In the code you have that is bad style, you have a problem with languages that don't use indentation to determine what to do with the code. Imagine I'm maintaining your code and see this:

if (condition)
    body();  // bad!

I decide to add a line to it, to make it this:

if (condition)
    body();  // bad!
    myconditionalfcn(); // Will always execute

The other two styles you have prevent this mistake, one by making the entire conditional a single line, and the other by ensuring I enter my new function inside the braces.

When working on someone else's project, you should never break their style. When working on your own project, you should strive for readability in your style--the problem with the second, in terms of readability, is that it can cause confusion like the above. A good editor will let you auto-correct this error, but it's (almost) always better to avoid it in the first place by not having single line conditionals split like that.

It does not apply to Android specifically. Like all indentation issue, is a question of tastes. Anyway using :

if (condition)
    body();  // bad!

could confuse someone reading fast the code, because it may be not clear where the condition statement ends. Personally I prefer the first style:

if (condition) {
    body(); 
}

For the following reasons:

1. it isn't ambiguous at all
2. With nowadays IDEs (like Eclipse) is even fast to write using auto-completion
3. It's faster to add other statements inside the brackets, and often you will need to do this.

Coding styles are guidelines, what is legal is what the language definition permits.

When they use the term legal in respect to coding styles, they just mean what they will accept. The example

if (condition)
  body();

is specifically singled out as it confuses indentation with execution, something that isn't actually part of the Java language specification. In other words, someone might look at

if (condition)
  statement1();
  statement2();

and think that both statement1 and statement2 are executed only when the condition is true. Note that this person would have made a mental mistake; a good coding style tries to minimize the number of mental mistakes which could occur in other people's minds.

Whether it is correct to permit

if (condition) statement1();

is open to debate. For many this is acceptable; however, it is really subject to the same issue as the above example. Java doesn't make decisions based on the type or amount of white space, it makes decisions based on the presence of any white space. In other words, you could confuse someone by doing this

if (condition) statement1(); statement2();

where statement2 is always executed; hoping to confuse them into believing that statement2's execution is somehow dependent on the condition. The reason that

if (condition) statement1();

is generally accepted has a lot to do with the extremely rare practice of seeing statements like

if (condition) statement1(); statement2();

but accepting the non-curly brace version has nothing to do with actually improving the code quality, it's just sometimes accepted because generally people don't write confusing "all-in-one-line" if statements.

With if statements, the only safe way to make sure that people don't associate behavior with white space is to always insert curly braces.

if (condition) { statement1(); } statement2();

may look odd, but it is guaranteed to provide enough visual cues that a person won't make a mental mistake of thinking that statement2's execution depends on statement1.

Finally,

if (condition) {
  statement1();
}
statement2();

will never confuse anyone. The only possible cost is the storage of a few extra white space characters and the addition of a couple of horizontal typed lines. Considering how much storage is available, I would say the storage argument is finally dead. The screen real estate argument still remains; but, sometimes forcing an idea to be clear is worth a few extra lines on the screen (and screens are much larger today than they were in the past). When one considers the cost of wasted manpower in pursing "wrong ideas" due to "mental mistakes" in reading code; it seems that a few extra curly braces here or there can pay for themselves nicely.

Besides, if you are using tons of if statements back to back, you probably would be better off using a switch or polymorphism.

IMHO, when talking about code formatting there cannot ever be used words like "legal" and "illegal". Illegal in my mind is something that acts harmful above your application. Right or bad formatting cannot cause your program to fail, formatting is simply a way to make your code readable. If you're working in a team you should consider using right formatting to make your teammates understand your code. When you're working alone it doesn't matter, you can write whatever you like with your own formatting style. That's just my opinion.

P.S. I personally use only the first style, it helps preventing silly mistakes.

Personal code style preference combined with a strict adherence to style standards for contributing to their project.

If you've no interest in committing any code to AOSP I wouldn't worry too much about it.

For readability, I prefer

if (conditiontest) doOneThing();

over either of these

if (conditiontest) { doOneThing(); }

if (conditiontest) {
     doOneThing();  }

if (conditiontest) { 
     doOneThing(); 
     }

This mostly just my opinion. But I think it enhances it's succinctness.