Some trial-and-error of this code in JSLint
"use strict";
var that="dd";
function $(x){return x;}
$('#'+ $(this).attr('id').replace('control-', 'legend-')).fadeIn();
$(this);
shows me what's wrong: you're using this
as a parameter. Changing both this
es to that
s doesn't trigger the error.
As the specification says:
If this is evaluated within strict mode code, then the this value is not coerced to an object. A this value of null or undefined is not converted to the global object and primitive values are not converted to wrapper objects. The this value passed via a function call (including calls made using Function.prototype.apply and Function.prototype.call) do not coerce the passed this value to an object (10.4.3, 11.1.1, 15.3.4.3, 15.3.4.4). [my emphasis]
As John Resig writes,
Finally, a long-standing (and very
annoying) bug has been resolved: Cases
where null or undefined is coerced
into becoming the global object.
Strict mode now prevents this from
happening and throws an exception
instead.
(function(){ ... }).call( null ); // Exception
As you showed, using your line of code inside a function declaration throws an error in JSLint, whereas using it inside a function expression doesn't. It looks like JSLint erroneously parses the function declaration, sees this
, that's still undefined at that moment, and throws an exception.
At this point, I think I have to quote Juriy Zaytsev (‘kangax’):
Does it really matter?
It’s good to understand that strict mode is not a requirement, but is
merely an option. It is there to
provide stricter rules for those who
need it, and are willing to cope with
(and enjoy) consequences.
Update: At last I found an explanation. If you read this thread, especially from message #1512 onwards, you'll read that
The point of ES5/strict is to prohibit
leaking of the global object,
something that ES3 does promiscuously.
ES5/strict does some of its work
dynamically, and some of its work
statically. JSLint does all of its
work statically, so it must be even
more restrictive in order to best help
you get your program right. [Douglas Crockford in #1553]
I have to admit that he has a valid point here: if your goal is to avoid global namespace pollution, you shouldn't use function declarations, but function expressions inside a private namespace, anyway. But I agree with others in the mentioned thread that the error message should be more explicit (and probably throw a warning on encountering a function declaration).