J.R. said:
"must not" was exaggerated on purpose, because using many var statements
is an antipattern in JavaScript.
In your humble opinion (which may not even be your opinion but that of the
author of some botched book you read instead, and now you think you know the
language and its "best practices").
The advantages of using the Single var Pattern at the top of your
functions are:
You are confusing two concepts here.
- there's a single place to look for all the local variables needed by
the function;
The comma operator does not help with this.
- prevention of logical errors when a variable is used before it’s
defined;
The comma operator does not help with this.
- Helps you remember to declare variables and therefore minimize
globals;
The comma …
- only one var statement means less code to type and a reduction
in the file size.
Sometimes. Because for readable code, you will have to indent the second,
third aso. line. In particular, with the style you used above, you do not
save or add *any* byte. If this is not obvious to you, look more carefully:
var.el.=....,.........
....h =....,..........
....w.=....,..........
....i,.j,.len,....,.z;
vs.
var.el.=....;.........
var.h.=....;..........
var.w.=....;..........
var.i,.j,.len,....,.z;
At any rate, the potential savings are so very small compared to what
trimming comments, minimization and gzipping can achieve that this is not a
convincing argument. Taking my current local object.js as an example:
awk '
BEGIN {
total = 0;
var_lines = 0;
print;
}
/^[[:space:]]*var/ {
total += length();
var_lines++;
}
END {
print "LOCs: " NR;
print "var LOCs: " var_lines;
print "avg(length(var LOCs)): " total/var_lines " bytes";
savings = 2 * var_lines;
print "Potential savings (best case): " savings " bytes (2 * " var_lines
")";
"wc -c " FILENAME | getline wc_out;
split(wc_out, data);
filesize = data[1];
print "File size: " filesize " bytes";
print "Potential savings (best case): " savings/filesize * 100 " %";
}' \
object.js
LOCs: 2009
var LOCs: 66
avg(length(var LOCs)): 27.8788 bytes
Potential savings (best case): 132 bytes (2 * 66)
File size: 55694 bytes
Potential savings (best case): 0.237009 %
----
2 bytes per `var' line because changing
var.foo;\n
var.bar;\n
to
var.foo,\n
..bar;\n
saves two characters on the second, third etc. line per variable
declaration. However, it should be noted that the more readable form is
var\n
..foo,\n
..bar;\n
which saves *nothing* with \n = <LF> but *adds* one byte with \n = <CR><LF>
as it means removing a space [−1] and adding a newline [+1|+2] on the first
line, adding two spaces [+2] on the second line, and removing "var" (3 bytes
[−3]) and adding a space [+1] on the third line).
With tab indentation, it is a change of
var.foo;\n
var.bar;\n
to
var\n
<HT>foo,\n
<HT>bar;\n
which means removing one space [−1] and adding one newline [+1|+2] on the
first line, adding one <HT> [+1] on the second line and saving 3 bytes [−3]
on the second line (a total of only 1 or two 2 saved bytes). (However, tab
indentation may require additional adjustments at the reader's, and is
therefore also not recommended for posting to Usenet.)
There are patterns in any programming language usually adopted by
programmers as "best coding practices". And it happens to other fields
of study too. See <
http://en.wikipedia.org/wiki/Best_Coding_Practices>
If you get a bunch of authors (books, blogs, etc.) that state the same
"best practices" in any programming language, then you can bet who is
wrong or right...
No, it doesn't, although I know you're a very experienced and smart
programmer. However, if you published some evidence such as performance
tests, etc., then you could state that some practice should be either
considered a good one or avoided altogether.
Your logic is flawed: <
http://en.wikipedia.org/wiki/Ipse_dixit>
PointedEars