Is it ok if I omit curly braces in Java? [closed]

I've searched for this, but couldn't find an answer and for whatever reason I was too ashamed to ask professor, due to that feeling when hundreds of people stare at you...

Anyhow, my question is what's the importance of having brackets? Is it OK if I omit them? Example:

for (int i = 0; i < size; i++)  {
   a += b;
}

vs

for (int i = 0; i < size; i++)
   a += b;

I know both of them will work, but if I omit the brackets (which I tend to do a lot, due to visibility) will that change anything, anything at all? As I said, I know it works, I tested it dozen of times, but now some of my uni assignments are getting larger, and for some reason I have irrational fear that in the long run, this my cause some problems? Is there a reason to fear that?

It won't change anything at all apart from the maintainability of your code. I've seen code like this:

for (int i = 0; i < size; i++)
   a += b;
   System.out.println("foo");

which means this:

for (int i = 0; i < size; i++)
   a += b;
System.out.println("foo");

... but which should have been this:

for (int i = 0; i < size; i++) {
   a += b;
   System.out.println("foo");
}

Personally I always include the brackets to reduce the possibility of confusion when reading or modifying the code.

The coding conventions at every company I've worked for have required this - which is not to say that some other companies don't have different conventions...

And just in case you think it would never make a difference: I had to fix a bug once which was pretty much equivalent to the code above. It was remarkably hard to spot... (admittedly this was years ago, before I'd started unit testing, which would no doubt have made it easier to diagnose).

Using braces makes the code more maintainable and understandable. So you should consider them by default.

I sometimes skip using braces on guard clauses to make the code more compact. My requirement for this is that they're if statements that are followed by a jump statement, like return or throw. Also, I keep them in the same line to draw attention to the idiom, e.g:.

if (!isActive()) return;

They also apply to code inside loops:

for (...) {
  if (shouldSkip()) continue;
  ...
}

And to other jump-conditions from methods that are not necessarily at the top of the method body.

Some languages (like Perl or Ruby) have a kind of conditional statement, where braces don't apply:

return if (!isActive());
// or, more interestingly
return unless (isActive());

I consider it to be equivalent to what I just described, but explicitly supported by the language.

There is no difference. The main problem with the second version is you might end up writing this:

for (...) 
  do_something();
  do_something_else();

when you update that method, thinking that do_something_else() is called inside the loop. (And that leads to head-scratching debug sessions.)

There is a second problem that the brace version doesn't have, and its possibly even harder to spot:

for (int i=0; i<3; i++);
  System.out.println("Why on earth does this print just once?");

So keep the braces unless you have a good reason, it is just a few keystrokes more.

I think that loosing curly braces is good, if you are also using auto-format, because than your indentation is always correct, so it will be easy to spot any errors that way.

Saying that leaving the curly braces out is bad, weird or unreadable is just wrong, as whole language is based on that idea, and it's pretty popular (python).

But I have to say that without using a formatter it can be dangerous.

For most cases, the answers mentioned so far are correct. But there are some disadvantages to it from the security perspective of things. Having worked in a payments team, security is a much stronger factor that motives such decisions. Lets say you have the following code:

if( "Prod".equals(stage) )
  callBankFunction ( creditCardInput )
else
  callMockBankFunction ( creditCardInput )

Now lets say you have this code is not working due to some internal problem. You want to check the input. So you make the following change:

if( "Prod".equals(stage) )
  callBankFunction ( creditCardInput )
else
  callMockBankFunction ( creditCardInput )
  Logger.log( creditCardInput )

Say you fix the problem and deploy this code (and maybe the reviewer & you think this won't cause a problem since its not inside the 'Prod' condition). Magically, your production logs now print customer credit card information that is visible to all the personnel who can see the logs. God forbid if any of them (with malicious intent) gets hold of this data.

Thus not giving a brace and a little careless coding can often lead to breach of secure information. It is also classified as a vulnerability in JAVA by CERT - Software Engineering Institure, CMU.