New rule: consistent-return

[LinusU]

Suggesting that we include the rule consistent-return

---

This rule is aimed at ensuring all return statements either specify a value or don't specify a value.

The following patterns are considered warnings:

function doSomething(condition) {

    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {

    if (condition) {
        return;
    } else {
        return true;
    }
}

The following patterns are considered okay and do not cause warnings:

function doSomething(condition) {

    if (condition) {
        return true;
    } else {
        return false;
    }
}

---

I found the rule while comparing which rules xo has versus standard here: #216 (comment)

[feross]

On the surface, this seems like a good rule. But it's actually not that well implemented, and it gives a ton of false positives. 23 repos in the test suite will fail if you enable this rule.

standard has to be pragmatic -- we can't enable flaky rules!

Of particular note, the popular return cb(err) pattern confuses the rule quite a bit:

      rs.pipe(through.obj(function (data, enc, cb) {
        if (data.value.toString()[0] === '{') return cb()
        if (verify) {
          verify(u, val.message, val.signature, function (_, valid) {
            m.valid = !!valid
            processor(m, cb)
          })
          return
        }
     })

You can play around with potential rule changes by modifying eslint-config-standard and running the standard tests with npm test.

[LinusU]

Ahh, that makes very much sense.

I'll try to play around with the rules and see if there is anything that we can learn from xo and others :)

[feross]

Great idea, thanks!
On Tue, Aug 4, 2015 at 3:49 PM Linus Unnebäck notifications@github.com
wrote:

Ahh, that makes very much sense.

I'll try to play around with the rules and see if there is anything that
we can learn from xo and others :)

—
Reply to this email directly or view it on GitHub
#221 (comment).