I have e JS code with some infinite loops (we're using node-fibers to allow things to happen).

ESLint hates:

while (true) {

}

because of the constant condition.

The following is allowed though:

for(;;) {

}

Beyond just feeding the lintbeast, are there any objective reasons to favour for over while (or vice versa)?

NOTE: This question is explicitly requesting objective reasons and so is not simply opinion based.

I have e JS code with some infinite loops (we're using node-fibers to allow things to happen).

ESLint hates:

while (true) {

}

because of the constant condition.

The following is allowed though:

for(;;) {

}

Beyond just feeding the lintbeast, are there any objective reasons to favour for over while (or vice versa)?

NOTE: This question is explicitly requesting objective reasons and so is not simply opinion based.

• javascript
• eslint
• node-fibers

• 2 Since performance is not usually a concern in infinite loops... who cares? – ssube Commented May 26, 2016 at 16:36
• 10 Not sure why so many are downvoting, this seems like a legitimate question. – dmeglio Commented May 26, 2016 at 16:37
• 2 @ssube well performance isn't the only consideration in a well formed program... so I (and potentially others) care. Hence the question. – Dancrumb Commented May 26, 2016 at 16:38
• 2 This looks like an opinion based question. The while loop is the convention most people use, because it reads in a spoken word fashion. Ie "while true" is universally known to indicate an infinite loop, "for semicolon semicolon" does not immediately indicate that. – Bryce Drew Commented May 26, 2016 at 16:41
• 1 @BryceDrew the question is not "is it a good practice", it's "why does this particular library hold that opinion" which is in fact not opinion based. If you read my answer - there is also nothing opinion based about it. – Benjamin Gruenbaum Commented May 26, 2016 at 16:48

2 Answers 2

These rules about infinite loops are from before generators were a thing and are not even aware of fibers.

Under the assumption that every function never suspends and returns (like a generator, async-keyword function or a fiber) the rule makes a lot of sense to warn against constants in loops.

Now that times have changed - the rule no longer makes sense and what you're doing is perfectly fine.

If we check the eslint repo it was discussed and deemed "not important enough to acknowledge" in the meantime:

I don't think this makes sense as a built-in exception. If you're doing that, then it's best to manually disable the rule in the generator using a ment.

The workaround for(;;) was suggested but everyone involved understands it's a hack for this particular case.

Disable the rule.

The no-constant-condition rule of eslint does allow you to ignore while (true) loops, by configuring checkLoops: "allExceptWhileTrue".

Add this configuration to your .estlintrc JSON file, or equivalent:

{
  "rules": {
         "no-constant-condition": ["error", { "checkLoops": "allExceptWhileTrue" }]
  }
}

Alternatively, you can add a ment in the JavaScript file itself:

/*eslint no-constant-condition: ["error", { "checkLoops": "allExceptWhileTrue" }]*/

while (true) {
    doSomething();
};