Tslint: Complement to [one-line]?

[Bartvds]

Is it possible to enforce this style of having some blocks on the next line from the expression preceding them? Like the reverse of [one-line]

if (foo) {
    // ...
}
else {
    // ...
}

try {
    // ...
}
catch (e) {
    // ...
}

[ashwinr]

one-line does more than that. It also enforces braces on the same line. I can foresee a rule that enforces separate lines for _both_ braces and associated expressions (like else and catch), but I think it's a little awkward to enforce braces on the same line but allow expressions on a new line. If you agree, I can see the case for a next-line rule.

[ashwinr]

One more thing: If we start having rule complements, we now have to handle invalid configurations. Right now, rules are mutually exclusive and that makes things a lot simpler. I'm cautious to introduce dependencies across rules (e.g. both one-line and next-line cannot be enabled within the same configuration). But, you can always create this rule locally, it's a trivial change in https://github.com/palantir/tslint/blob/master/src/rules/oneLineRule.ts :smile:

[Bartvds]

It doesn't necessarily have to be 'complement'.

The arguments for this style are that the closing brace enforces a natural blank line-end. More importantly the (highlighted) keyword is now on the left edge of the code blocks, very visible, in same way as many other statements (var, return etc).

This is a very common style in any bracy language so I think it should work in the standard rules.

[ashwinr]

Even then, a configuration with both one-line and this new rule cannot be enabled simultaneously, because one of the rules will always show an error. Generally, we should avoid having conflicting rules. The only solution I see is to make this an option of the one-line rule, maybe called keyword-on-new-line.

[Bartvds]

Yes, they conflict, they should probably be options of one single rule (the name one-line is maybe not ideal).

Maybe call it something with 'wrapping & braces' like in WebStorm? I have no specific preference to how it is implemented or named though.

[tfrijsewijk]

Is there any news on this? I would really like to enforce if/else etc on the next line. This is a very old issue, do you have a solution for your rule-conflict situation? (ie: one-line and next-line) can be enabled simultaneously.

Maybe it should be possible to enable them at the same time. Then you can do something like

    "one-line": [
      true,
      "check-open-brace",
      "check-else",
      "check-whitespace"
    ],
    "next-line": [
      true,
      "check-finally",
      "check-catch"
    ]

Why one would want this, don't ask me.. But it's always nice to find a use-case to unwanted behaviour ;-) Just let the last definition of check-* win

[glen-84]

I am/was considering using a PHP PSR-2 style, where classes, interfaces, and methods have the brace on a new line, and if/else/try/catch/etc. have it on the same line.

Simple example:

class Example
{
    public method(): void
    {
        if (true) {
            // ...
        } else {
            // ...
        }
    }
}

I think it looks neat, albeit not so common in the JS/TS world.

It might make sense to support this as well (i.e. allow each brace position to be specified individually).

[linusbrolin]

I also prefer using next-line for else, catch and finally.
The rules would look something like this for me:

"one-line": [
  true,
  "check-open-brace",
  "check-whitespace"
],
"next-line": [
  true,
  "check-else",
  "check-catch",
  "check-finally"
]

Basically, I want to force open braces to be on the previous line, and close braces to be on a new line.
Similarly, I do not want to allow this:

if (test === 1) {
  // do stuff
} if (test !== 1 && test2 === 1) {
  // do stuff
} else if (test !== 1 && test2 === 2) {
  // do stuff
} else {
  // do stuff
}

Instead, I would want to force the above like this:

if (test === 1) {
  // do stuff
}
if (test !== 1 && test2 === 1) {
  // do stuff
}
else if (test !== 1 && test2 === 2) {
  // do stuff
}
else {
  // do stuff
}

It makes it way more readable in my opinion.
Also, it makes it possible to put a debug breakpoint on each if statement, if one would want to, which would not be possible in the one-line approach.
I just think it makes more sense.

[JoshuaKGoldberg]

Closing this issue per #4534. Thanks for the discussion, folks!