jshint: Regular parameters should not come after default parameters

@derwaldgeist Sure! Here’s an example .jshintrc file that would silence the warning:

{
  "esversion": 6,
  "-W138": true
}

Just want to mention that such kind of signature is a part of redux code samples. Look for the line:

function counter(state = 0, action) {

so, it is widely used, IMHO.

@thalesfsp : Add /* jshint -W138 */ add the beginning of your file. (Make sure you’re using jshint v2.9.1 or newer)

With ‘callback’ being widely used as the last parameter of a function, this lint warning seems rather silly to me

How can I disasable it…?

Can you provide a sample of error which can appear with such signature?

The only runtime error you’ll encounter is calling like: counter() and counter(undefined), but that’s not my point. My point is that’s terrible design and places an undue burden on the programmer and on their tooling. For example, a minifier could reasonably analyze the following:

function counter(action, state = 0) {
  return [action, state];
}
counter({});
counter({}, 0);
counter({}, undefined);

And produce:

function c(a,s=0){return[a,s]}
c({});
c({});
c({});

Whereas, putting the the default first:

function counter(state = 0, action) {
  return [state, action];
}
counter(0, {});
counter(undefined, {});

would produce:

function c(s=0,a){return[s,a]}
c(0, {});
c(undefined, {});

That’s a fairly contrived example, but still illustrates my point that it makes the use of a default parameter completely and utterly pointless.

For me it’s just a property of language.

Just because you can, doesn’t mean you should.

This sort of pattern is absolutely the definition of “lint”.

so, it is widely used, IMHO.

I strongly disagree with the implication that a pattern which appears in redux is indicative of something “widely used”. I looked through redux and found examples of counter(undefined, action) and I’m left wondering what the point of this could possibly be, considering every single one of them actually requires the action argument, or face a runtime error. If the action is always required and the state is optional, why require calls that must explicitly pass undefined—that defeats the purpose of default parameter values.

…I’m tempted to file a bug.

---

That said, it remains unclear if this warning is appropriate at all.

I believe it is, and anyone that doesn’t want the warning is welcome to turn it off.

Feel free to close this @jugglinmike

Requiring all call sites to pass an explicit undefined, for the sake of getting around a badly designed call signature is considered a bad practice and an incorrect use of default parameters.

Stumbled upon the same problem with Redux. Can this be disabled in the .jshintrc config file, please?

I’m still of the opinion that in the absense of a tangible hazard (and even in the presence of otherwise-undesirable patterns), JSHint should remain silent. That said, I’m having trouble understanding how @txm’s example is distinct.