💭 Formatter feature request: comment before `else` keyword

[AlchemistCamp]

One of the most contentious decisions in Prettier and the reason I personally no longer use it for any projects, was its forcing the removal of breaks before else blocks: prettier/prettier#840

To illustrate two issues with this, consider the following code:

  // comment for if block
  if (cond1) {
    doFoo(tree, data);
    if (cond2) {
      collect(tree.left, data, depth + 1);
      collect(tree.right, data, depth + 1);
    }
  }
  // comment for else block
  else {
    doBar(data);
  }

As it is now, Rome will throw errors suggesting the following format

  // comment for if block
  if (cond1) {
    doFoo(tree, data);
    if (cond2) {
      collect(tree.left, data, depth + 1);
      collect(tree.right, data, depth + 1);
    }
  } else {
    // comment for else block
    doBar(data);
  }

The problems with eliminating the break before the else are that it now lines up the else block with the wrong conditional and that it eliminates the clearest place for the else block comments.

I don't see much upside in a linter being rigid to this degree, and based on the the discussion on the Prettier issue linked above, many others would agree.

---

Edit: Since the title was changed, I'll reiterate:

I strongly prefer not removing the break before else, even in cases where there are no comments. The else should line up with the if it corresponds to, not an inner one.

[bitpshr]

Thanks for taking the time to file this @AlchemistCamp. I'm also in favor of breaking before else statements, I feel that the advantages are objective in terms of comment legibility.

[milesj]

What about?

  // comment for if block
  if (cond1) {
    doFoo(tree, data);
    if (cond2) {
      collect(tree.left, data, depth + 1);
      collect(tree.right, data, depth + 1);
    }
  // comment for else block
  } else {
    doBar(data);
  }

[bitpshr]

@milesj that syntax is especially common and admittedly pretty readable, but it's technically semantically-off since the comment for the else block is inside the if block.

[ematipico]

Would this formatting choice applied only in presence of comments or always?

[milesj]

@bitpshr Interesting point. I've never thought about it that way, as semantics in relation to comments don't mean anything to me. They describe the following line/block and nothing more.

[noftaly]

What about?

  // comment for if block

  if (cond1) {

    doFoo(tree, data);

    if (cond2) {

      collect(tree.left, data, depth + 1);

      collect(tree.right, data, depth + 1);

    }

  // comment for else block

  } else {

    doBar(data);

  }

The main downside I see is that if we fold the if block, we won't see the comment of the else block anymore, but still the comment of the if block.

I'm also in favor of breaking before else statements 😄

[AlchemistCamp]

Thanks for taking the time to file this @AlchemistCamp. I'm also in favor of breaking before else statements, I feel that the advantages are objective in terms of comment legibility.

Thanks for taking it under consideration!

[AlchemistCamp]

What about?

  // comment for if block
  if (cond1) {
    doFoo(tree, data);
    if (cond2) {
      collect(tree.left, data, depth + 1);
      collect(tree.right, data, depth + 1);
    }
  // comment for else block
  } else {
    doBar(data);
  }

This would still have the else block lined up with cond2, instead of cond1. It's clearer to have the logically connected blocks indented the same amount.

---

Apologies for the close and reopen noise! I'm on mobile and hit the close & comment button by mistake.

[richardaum]

I'd agree with the Prettier decision by moving the comment inside the else block because you could have a lot of comment lines (or a large comment block) - it could hurt the legibility where you could quickly identify if it is about an if/else statement and not an isolated if.

  // comment for if block
  if (cond1) {
    doFoo(tree, data);
    if (cond2) {
      collect(tree.left, data, depth + 1);
      collect(tree.right, data, depth + 1);
    }
  }
  // what if you 
  // had a lot of comments lines 
  // here?
  // it's easy to forget this is about
  // an if/else statement.
  // moving the comment lines to the inside of the else
  // statement quickly reveals
  // what is it about.
  else {
    doBar(data);
  }