Comment between if/else is formatted strangely

if(x) {
}
// comment
else {
}

output:

if (x) {
} else
  // comment
  {
  }

[jlongster]

I’m very tempted to do what @rafayepes suggests. It seems odd that you can inject comments and “stop” our styling rules. Normally we enforce this:

if() {
} else {
}

So it seems only natural do move them inside the block. It seems like a good place to enforce a consistent place for comments that are documenting the else conditions. Also, we want to implement the same behavior for all statements that have alternate blocks like try/catch.

It also removes the need for too much special-casing in our code. As long as we move the comment to the right place, it will “just work” 😃

If we are OK with that, here’s what I propose:

• In the code that handles leading comments in attach, we can check if there is any syntax between the comment and the followingNode. There is already code in breakTies that does this. This works because the else syntax sits between the comment and the block’s {, so we know something special is going on.
• If that’s the case, and the followingNode is a block, then we attach a leading comment to the first node inside the block instead. This moves the comment inside the block.

That’s a bit more generic than special-casing if and will work for the catch statement of try/catch as well. Unfortunately it makes the comment code even more complicated, but I guess we need to do it.

[jlongster]

That already looks pretty good:

if (a)
  doSomething();
else
  // comment
  doSomethingElse();

Basically, it forces it to break, if people really want to avoid blocks. I prefer enforcing blocks but not sure I want to do that in this project. Hard to say when we should enforce something or not.