What is the point of the no-continue rule?

[callumlocke]

The official ESLint docs say "When used incorrectly it makes code less testable, less readable and less maintainable."

Does Airbnb agree with the above reasoning? If so, can you give an example of how continue makes code less testable and less maintainable?

(I'm not arguing against it btw, just want to understand why.)

[ljharb]

continue, like break, is GOTO. There are countless articles on the internet about GOTO being harmful.

In addition, this style guide discourages loops, which are the only places you'd need continue or break.

[deckar01]

continue is generally not used with a label. I think eslint needs to differentiate GOTO label usage from bare continue usage. When used without a label, continue is no different than a return statement in the body of a forEach loop.

I am going to disable this rule for my project. Would you be interested in added granularity for the no-continue rule if I proposed it?

[deckar01]

javascript/packages/eslint-config-airbnb-base/rules/best-practices.js

Line 128 in 90235ca

'no-labels': ['error', { allowLoop: false, allowSwitch: false }],

no-labels is already enabled.

[ljharb]

Loops themselves are banned by this gude; so there’s no use case for continue.

[deckar01]

I am using the latest version of the airbnb base config for eslint and it doesn't warn about for loops.

[deckar01]

Also, how would you generate an array with the numbers A..B without using a for loop? My guess is that it is less readable than

const range = [];
for (let x = A; x <= B; x += 1) {
  range.push(x);
}

[ljharb]

The guide is far more expansive than the linter config; rest assured, it will one day warn on for loops, to match the guide text.

The answer is you’d make a “range” abstraction, in which the implementation details are both irrelevant and fine to override linter warnings on, rather than writing a loop in your own code.

[SelaO]

Continue is not goto. That's like saying loops are goto.

[ljharb]

@SelaO no, it's not like saying that. Loops that use break or continue are goto.

[SelaO]

What's the difference between the following?

start:
...
if(x) goto start

and

start:
...
if(y) goto start
...
if(x) goto start

and

start:
...
if(y) goto end
...
if(x) goto start
end:

Now how are these examples (which almost look like nested loops and keep all the jumps inside the scope of the loop) are the same as this?

function foo(){
...
ARBITRARYLABEL1:
....
goto ARBITRARYLABEL2
}

function bar(){
...
goto ARBITRARYLABEL1
...
}

ARBITRARYLABEL2:

[ljharb]

@SelaO I’m not sure what you’re asking.

[MegaArman]

I actually don't currently use airbnbs rules, but am considering it after reading the discussion here.
continue should be banned, especially if you don't use loops (you shouldn't in 2018, but that's a whole different discussion).

I was once a continue, break, return everywhere, kind of dude and felt very clever for leveraging those features, but really it doesn't help your team. The less bouncing around you have to do when reading code the better. continue makes code harder to read for other people -you might not see why from your own code, but imagine working on a large codebase with lots of loops and if statements with continues scattered about... Do you really want to maintain code you can't read top to bottom in one shot? Bite the bullet, learn to write easier to read code even if it's initially harder to do.

Just for reference, in Scala the last line of code is automatically the return value if no return is specified and it's what they seem to encourage (disclaimer: I'm not a Scala expert, but just saying that there's things to be learned from other languages).

[SelaO]

@MegaArman
Loops are still useful in 2018 in many non trivial cases and will stay useful even in 2118, you can't do everything with map, reduce, filter.

See the example I gave above and tell me how continue is "bouncing around" like goto is.

but imagine working on a large codebase with lots of loops and if statements with continues scattered about

That's an invalid statement, if the code already become such a mess, then not having continue and breaks won't help you, loops shouldn't be huge, just like functions shouldn't be huge.
Banning basic coding concepts isn't a magic tool to make code more readable and maintainable, and oftenly can make the code even less maintainable (like more complex stopping conditions in no continue loops)