Why Firefox's strict JavaScript warnings are wrong
Firefox offers a strict JavaScript checking option. It can be enabled by either setting 'javascript.options.strict' to 'true' in about:config, or by enabling 'strict JavaScript warnings' in the Web developer extension.
It sounds like a nice idea, to help you with your script debugging. However, before you get carried away and start trusting it, I must strongly discourage its use. It encourages, and even enforces very bad programming style. So much so that it tells you not to write proper cross browser scripts. It even forces you to write scripts that cannot work cross browser. I am not impressed.
Let me explain the problem.
The idea of strict syntax checking is that it warns you if you are using a variable that you have not defined. That sounds good because it could tell you if you might be accidentally overwriting a variable from a parent scope.
But here is where it gets things wrong.
It does not warn you if you overwrite a variable that exists in a parent scope. But it does warn you if you do not use the var keyword the first time you assign a value to a variable. In JavaScript that is not really necessary since it will automatically create a variable in the global scope anyway. Still it doesn't hurt to do things properly and declare the variable using the var keyword. But since the only time you are really interested in that sort of error is when you overwrite the variable from the parent scope, it becomes useless for the one thing it could have been useful for.
To make matters worse, it applies this logic not only to normal variables, but also to properties of existing objects. This defies the whole concept of object detection, and as a result breaks the very essence of cross browser scripting. Take this well written script for example:
if( document.body.childNodes[10] == e.target ) {If there is no childNode, Firefox's strict syntax check will throw a warning, saying "Warning: reference to undefined property document.body.childNodes[10]". But I know it might not be defined, that is why I checked for it! And Firefox tells me off for checking for it.
The same stupidity would be applied to this valid code:
if( document.onclick == myFunction ) {In fact, it does this every time you reference a property that might not exist. Most importantly, this includes properties used when making cross browser scripts:
if( ( e.srcElement == this ) || ( e.target == this ) )What does it expect us to do? How are we supposed to write cross browser scripts when it tells us we are wrong to check for properties? At a guess, we have to ignore it, and simply accept it as an unnecessary warning. But if we are supposed to ignore it, what is the point in warning us in the first place. All it is doing now is confusing inexperienced authors, making them think they have done something wrong, when in fact, they were doing the world a service by actually doing things right for a change.
Variable declaration warnings should warn about variables, not properties. Otherwise, inexperienced authors will revert to using browser sniffing (because Firefox does not seem to mind that), and that is something that the Web could certainly do without.
Well, it does allow one thing;
if( document.onclick != null )But why would it allow this useless bit of code when it doesn't allow others? I fail to see why. Checking against null with inbuilt properties or returned values is a very bad thing to do. Why? Because browsers do not agree on what should and what should not be null.
For example, in Internet Explorer, an undefined event handler (such as document.onclick) is incorrectly returned as null. In Firefox, Opera, and the other standards compliant browsers, it is returned as undefined. And as another example, getAttribute incorrectly returns null in Firefox and Internet Explorer if the requested attribute has not been defined. In Opera 8, it correctly returns a blank string (Opera 9 now copies IE and Firefox for this exact reason). Blank strings never equate to null, so the response when checking against null would be inconsistent and not cross browser. Simply checking for if(!someVariable) instead of if(someVariable!=null) would work flawlessly in all browsers.
Teaching authors to use something that causes compatibility problems is never a good idea. I am also a little worried that it thinks my optimised while(n=getNext()) should be flagged as a "test for equality (==) mistyped as assignment (=)", but at least by the time someone starts using that sort of syntax, they usually know what they are doing, and will ignore the incorrect warning.
Please, do not send me emails saying you disagree. I am sure you might disagree, and I am sure you might find it useful for debugging your own scripts. But the simple fact is that I have received emails from readers telling me that my scripts were invalid and proposing the !=null "fix". If you still feel the compulsion to email me, I point you instead to some further reading, where some of my readers demonstrate that they all fell for Firefox's incorrect warnings, and didn't realise that the warnings were wrong (or why they were wrong). If you still decide to email me about this, all I will do is point you to those earlier conversations.
Sorry Mozilla, nice try, but this is one option that should be changed so that it does not cause problems for inexperienced web authors. Please fix it, or remove the broken option before it causes more trouble than it is worth.