has the same meaning as:
The second form gets rid of the
var token and is four characters shorter. But I think a minimisation tool would be quite bold to perform transformations like this, so programmers are better off doing this themselves. This is probably why Crockford’s style is to use one
var and let all the variables share it, cuddled with commas. It seems to be a commonly emulated style.
The «=null» is probably redundant because just a plain «var doc» on its own is going to initialise the doc variable with the
undefined value (ironically, there’s nothing undefined about
undefined apart from its name). Sure, subsequent code could tell the difference between
undefined but you’re unlikely to be actually interested in the difference. Because you could in principle write code that changed according to whether doc was
undefined («if(doc===undefined)» being the most obvious example) then a minimisation tool is very unlikely to be able to correctly make the transformation, again the burden is on the programmer.Observation: «undefined == null» is
true so code like «if(doc == null)» will continue to work anyway. Which leads me to…
When this sort of code is used for feature detection it probably has the same intent as «if(!flashcopier)» which is 5 characters shorter. Again because these two fragments don’t have quite the same meaning (for example, when flashcopier is 0) it’s up to the programmer to decide if one can be replaced by the other.
, which would then have a different behaviour in the two tests. The programmer will have to decide if the replacement code is acceptable.
Like the earlier <code>typeof</code> example the minimiser could use its knowledge of operator precedence to remove the parentheses in the condition expression: «if(match.index>c.index&&match.index<c.index+c.length)». I recommend that the programmer does <em>not</em> perform transformations like this merely in order to shrink their code a bit, it's way too error prone.This example suggests another space saving that might be made. The variable <var>match</var> could be renamed <var>m</var>. That would save 8 characters just in this line, another 4 in its declaration, and 4 each time the variable was used. This kind of transformation is amongst the most thorny however. If the programmer does it then readability may be sacrificed on the altar of bandwidth minimisation (to a certain breed of programmer that grew up using a language where the length of a variable's name affected its speed of execution, such parsimony may come naturally).
Two things here. The semicolon is redundant and can be removed. [ECMA 262-3] has bizarre and arcanely specified rules for when semicolons are required, but in this case they boil down to “it can be removed”. In fact a semicolon before a closing squiggly bracket, «}», can almost always be removed (bonus credit for knowing when it can’t).The other minimisation possible is that the entire «return false» statement is a candidate for removal, but the programmer has to do this. If instead of «return false» a function “drops off the bottom” then this is equivalent to «return undefined»; in a boolean context, if the function is being used in an
if for example, then
undefined is just as good as
false. Again, like the «var doc=null» and the «flashcopier==null» example, the programmer will have to decide whether the transformation is possible without breaking the program.
Could almost be replaced by «(i%2)?”:’alt’» (negating the condition and swapping the two alternatives) except that when «i%2» evaluates to
NaN these two expressions have different meanings. An automatic transforming tool could make the transformation if it could infer the type of i to be a finite number or if the programmer could declare it to the tool. There are quite a few transformations like this, where the transformation would be possible given only a little hint about the type. Incidentally if the programmer had written «i&1==0» then that could be automatically translated with no type inference needed.I was just about to wrap up when I saw…
var regex=new RegExp('^\\s*','g')
var statement per function, using commas to separate the variables (this also makes the code align with the semantics).