I'm confused with JSLint.

My code originally checked if div:jqmData("me") was undefined like so:

if ( typeof el.jqmData("me") == "undefined"  
   ? el.not(':jqmData(panel="main")').length > 0 
    : el.not(':jqmData(me="first")').length > 0 ){

}

JSLint plains that I should replace checking with typeof with ===, so I did like this:

if ( el.jqmData("me") === "undefined"  
   ? el.not(':jqmData(panel="main")').length > 0 
     : el.not(':jqmData(me="first")').length > 0 ){

}

JSLint doesn't plain anymore, but my nested if statement is broken, because I'm now always ending up with the 2nd if el.not(':jqmData(me="first")').length even when I should not.

Question:
Why does JSLint remend === over typeof == undefined? How es this breaks my logic?

Thanks for some enlightment...

I'm confused with JSLint.

My code originally checked if div:jqmData("me") was undefined like so:

if ( typeof el.jqmData("me") == "undefined"  
   ? el.not(':jqmData(panel="main")').length > 0 
    : el.not(':jqmData(me="first")').length > 0 ){

}

JSLint plains that I should replace checking with typeof with ===, so I did like this:

if ( el.jqmData("me") === "undefined"  
   ? el.not(':jqmData(panel="main")').length > 0 
     : el.not(':jqmData(me="first")').length > 0 ){

}

JSLint doesn't plain anymore, but my nested if statement is broken, because I'm now always ending up with the 2nd if el.not(':jqmData(me="first")').length even when I should not.

Question:
Why does JSLint remend === over typeof == undefined? How es this breaks my logic?

Thanks for some enlightment...

• javascript
• jquery
• undefined
• jslint
• typeof

• 10 x === undefined, not x === 'undefined' – zerkms Commented Nov 2, 2012 at 22:38
• @zerksm: please make it an answer! – frequent Commented Nov 2, 2012 at 22:39
• 4 Depending on what you're checking, there's an advantage in using typeof someVar === 'undefined' over someVar === undefined, namely that the former won't break if someVar isn't, in fact, defined. For example, if someVar hasn't been declared, you'll get a ReferenceError using the latter, while the former works without a hitch. See: stackoverflow./questions/4725603/… ( cc @zerkms ) – NullUserException Commented Jan 9, 2013 at 21:43
• @NullUserException: yep, makes sense for checking variables (as an opposite to properties) – zerkms Commented Jan 9, 2013 at 22:05
• Possible duplicate of Why does jslint tell me to use ===? – Matthew Simoneau Commented Dec 1, 2015 at 3:25

2 Answers 2

You've broken the parison logic. It's assumed you use

typeof el.jqmData("me") === "undefined"  

or

el.jqmData("me") === undefined

Personally I'd go with the latter.

And personally I think that this particular JSLint check in this particular case makes not much sense.

What zerkms wrote is correct. An explanation can help though, from https://github./jamesallardice/jslint-error-explanations/issues/10#issuement-18273885:

A modernization of style has occurred with undefined parison. ES5 guarantees that undefined is undefined. In strict mode, in parison with the old and new styles, the typeof "undefined" check is longer to type and is no longer necessary now that undefined can be pared directly.

See the JSLint discussion: https://plus.google./101248256976407044060/posts/Q5oFnnxG9oL

Crockford basically says that typeof "undefined" check is longer and slower and is unnecessary.