question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Proposal: Require an empty line between "switch-case" statements (newline-between-switch-case)

See original GitHub issue

Proposal:

Require an empty line between switch-break statements (newline-between-switch-break) #6619 (newline-between-switch-break)

Options

This rule has an object option:

  • "spaceAfterBreak": true (default).
  • "spaceBeforeBreak": false

Relative

  • The curlies should be covered by padded-blocks.
switch (value) {

     case 100000000000000:
          break;

    default:
          break;

}
  • Comments should be covered by lines-around-comment:

For consistency reasons comments are ignored and do not count as empty lines.

switch (value) {
     case 100000000000000:
          break;

    // comment
    default:
          break;
}

Examples

/*eslint newline-between-switch-break: "error"*/ or /*eslint newline-between-switch-break: [ "error", {"spaceAfterBreak": true }]*/

Example of correct code for this rule:

switch (value) {
     case 100000000000000:
          break;

     case 200000000000000:
          break;

     default:
          break;
 }

Example of incorrect code for this rule:

switch (value) {
     case 100000000000000:
          value
          break;
     case 200000000000000:
          break;
     default:
          break;
 }

/*eslint newline-between-switch-break: ["error", { "spaceBeforeBreak": true }]*/

switch (value) {
     case 100000000000000:
          value += 100;

          break;
 }

Example of incorrect code for this rule:

switch (value) {
     case 100000000000000:
          value += 100;
          break;
 }

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:2
  • Comments:21 (13 by maintainers)

github_iconTop GitHub Comments

3reactions
btmillscommented, Jul 8, 2016

Nice examples! That helps clarify the problem. I’m envisioning the newline-before-return equivalent for break and continue as being almost identical to the return version, specifically in that it would exclude any statement that is alone in its block.

What about this?

  • "newline-before-flow-control": ["error", "always/never"]: require an empty line before break or continue statements
  • "newline-between-switch-case": ["error", "always/never", { "fallthrough": "never"}]: require an empty line between the cases (and default), if present) of a switch statement. The object argument for fallthrough would only be applicable if the rule were set to "always".
/*eslint newline-before-flow-control: ["error", "always"]*/
/*eslint newline-between-switch-case: ["error", "always", { "fallthrough": "never" }]*/
switch (foo) {
    case a: // newline before (or lack thereof) is controlled by padded-blocks
        doSomething();

        break; // newline before because `break` follows another statement

    case b: // newline before because newline-between-switch-case "always"
        break; // no newline before because `break` is alone in the `case`

    case c: // newline before because newline-between-switch-case "always"
    case d: // no newline before because newline-between-switch-case fallthrough "never"
        doAnotherThing();

        break; // newline before because `break` follows another statement

    default: // newline before because newline-between-switch-case "always"
        throw new Error("This should never happen");
}

for (let i = 0; i < arr.length; i++) {
    if (goodEnough(arr[i])) {
        break; // no newline before because `break` is alone in the block
    }
}

// Your examples with these options:
switch (value) {
     case 100000000000000:
          break; 

     case 200000000000000:
          value += 1;

          break; 

     default:
          break; 
}

for (let index of [, ]) {
    if (index++) {
        break;
    } 
}

for (let index of [, ]) {
    if (index++)
        break;

    continue;
}

for (let i of [, ]) {
    break;
}

for (let i of [, ]) 
    break;

// You had `for (let i of [, ]); break;`, meaning `break` is not in the loop. Was that intentional? I'll do both.
for (let i of [, ]);

break; 

for (let i of [, ]) break;

Is that code formatted more like what you want?

2reactions
lukeapagecommented, Jul 17, 2016

I wanted this rule (newline-between-switch-case), but didn’t want to wait for this to be accepted, so have implemented in a plugin - https://github.com/lukeapage/eslint-plugin-switch-case Please feel free to use the code as the basis for putting this rule in core (might need a bit more tidying/documentation/code formatting)

Read more comments on GitHub >

github_iconTop Results From Across the Web

eslint: New-line after case statement inside switch
I want to add an eslint rule, which forces a new line after each case-statement inside a switch- ...
Read more >
padding-line-between-statements - Pluggable JavaScript Linter
This rule requires or disallows blank lines between the given 2 kinds of statements. Properly blank lines ... "case" is case clauses in...
Read more >
Selection statements - if , else and switch - Microsoft Learn
The if , else and switch statements select statements to execute from many possible paths based on the value of an expression.
Read more >
"switch case" clauses should not have too many lines of code
The switch statement should be used only to clearly define some new branches in the control flow. As soon as a case clause...
Read more >
Switch statement - Wikipedia
NET, Java, and in many other types of language, using such keywords as switch , case , select or inspect . Switch statements...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found