This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why avoid increment (“++”) and decrement (“--”) operators in JavaScript?
I'm a big fan of Douglas Crockford and his excellent book, JavaScript: The Good Parts. I also use his JSLint tool on an hourly basis before checking in any code to our repository, as is good sense.
One thing I've noticed when running code through JSLint is its insistence that the ++ increment operator is somehow evil. I know I can turn certain rules off, but that's cheating ;). Crockford mentions his dislike on page 112 of JS: TGP...
In my own practice, I observed that when I used ++ and --, my code tended to be too tight, too tricky, too cryptic. So, as a matter of discipline, I don't use them any more. I think that as a result, my coding style has become cleaner.
That's all very lovely, but he doesn't give any examples of the way he codes them now. I assume he's doing something like...
var i;
i = 0;
i = i + 1;
Again, great, but I've got a few basic 'for loops' in my JS code, as I imagine many people have, and I've always used the standard syntax...
for (i = 0; i < myArray.length; i++) {
// Loop Stuff
}
Am I missing something? What's the cleanest and/or best way to increment/decrement?
I think this is rather controversial, and I personally stick to i++ in loops. Of cource, you can replace it with i = i + 1 in your loop statement, to be fully compliant to JSLint.
There aren't real alternatives to increment and decrement numerical values in JavaScript. You can often use Array.forEach() and/or Object.keys() in order to prevent numerical indexes.
The only tricky thing I see in autoincrement/decrement operators (and I'm quite surprised that no one here pointed that out) is the difference between prefix (++i) and postfix (i++) versions. I also believe that autoincrement/decrement operators are slightly more efficient, in general. Besides this, I think the choice is based mainly on aesthetics, especially in javascript.
to pass JSLint I now always do:
for (var i = 0; i < myArray.length; i+=1) {
// Loop Stuff
}
In C/C++ this is important, especially with arbitrary iterators and pre/post increment semantics. Also, random access vs forward-iterators.
In Javascript it's more about aesthetics than anything else. Unless you're dealing with strings. "1"+1 is "11".
I would say that ++i is an idiom that's worth being consistent with.
JSLint is wrong.
Personally, I see nothing wrong with the ++/-- operators for incrementing and decrementing. While something like i = i + 1; may be easier for new coders, the practice is not rocket science once you know what the operators stand for.
Regarding loop, one original idea can be using such loop to avoid all kinds of numbers:
var a = [];
for (var i in " ")
a.push("Loop iteration here");
alert(a.join("\n"));
Meaning iterate over a string, there will be amount of iterations equal to the string length - 5 in the above example.
Live test case: http://jsfiddle.net/vTFDP/
Related
My question is more a curiosity question on for-loop style.
While reading some old code by others, I encountered a style I haven't seen before.
var declaredEarlier = Array
for(var i=0, length=declaredEarlier.length; i < length; i++) {
//stuff
}
I had never seen declaring a length before use and since this is an old app, was this kind of style a C/C++/old Java carryover? or was this developer unique?
Is there any benefit for declaring length that way instead of doing what I normally do:
for(var i=0; i < declaredEarlier.length; i++) {
//stuff
}
If this has been asked before, I could not find it. And if it's not stackoverflow applicable, which forum would be better to ask?
There are two reasons you might grab the length up-front like that:
In case the length may change (remember, JavaScript arrays aren't really arrays* and their length is not fixed) and you want to use the original length to limit the loop, or
To avoid repeatedly looking up the length on the object, since you know it's not going to change
The first is obviously substantive; the second is style and/or micro-optimisation.
* Disclosure: That's a link to a post on my anemic little blog.
for the first style the value of declaredEarlier can change so you need to use it
like that length=declaredEarlier.length
but for the second style you already know the value you dont need to calculate it again
Because of JSLint, I almost always use i += 1 to increment a JavaScript for loop, but for quick and dirty scripts, I use i++ instead.
However, I see a lot of for loops in other people's code in which they increment i by doing ++i instead.
As far as I know, there is no difference in meaning between i++ and ++i, and jsPref shows no difference in performance.
As such, I'm wondering where the convention of doing ++i comes from and why people tend to do it.
Does anyone know why a lot of JS coders tend to prefer ++i over i++ when incrementing the counter in a for loop?
Thanks.
The difference is that i++ returns the value of i before incrementing and ++i the value of i after incrementing. There is no difference if you ignore the return value, e.g. in:
for (var i = 0; i < 10; i++) {
}
The habit of using ++i over i++ comes from C, where people were worried that storing the old value for i in i++ would incur a performance penalty.
Way back in the day (we're talking IE6/7 here!), I recall benchmarking both forms and found that there was a small performance improvement with ++i instead of i++. My (unproven) theory was that a non-optimizing JS engine had to do a tiny bit more work in the i++ case: it had to save the previous value in case it would be used - and being a non-optimizing engine it didn't realize that the value would in fact not be used and didn't need to be saved.
However, with modern browsers there is no significant difference. If anything, i++ seems to be a tiny bit faster in many browsers.
Here are some tests of a variety of different loops:
http://jsperf.com/mikes-loops/5
Look for the results for "Traditional Loop" (this uses ++i) and "Traditional Loop with i++".
Regarding JSLint's requirement that one should never use ++i or i++ but only use i += 1 instead, that is simply insane and over-controlling, like so many other things in JSLint.
Personally I recommend JSHint instead. It is less dogmatic, much more practical, and easier to customize to your own style.
In JS and PHP it does not make any difference, I think even in Java it does not make any difference but in pure c when compiler is not optimizing code it does, and that is why a lot of people use ++i because they are used to it from c.
EDIT:
This is an answer for JS if you want history of pre and post increment searc C/C++ pre/post increment. Or see comments on #Orvev's answer.
There is a difference, however not when used in a for loop.
In an expression, i++ evaluates to the previous value of i, and then i is incremented. ++i increments first, and evaluates then.
For this reason, some programmers prefer to write ++i in their for-loops — either because they're used to it, or because they feel it is "more right" somehow.
edit: More probable is the solution Overv proposed: a relict from C.
I've put together a jsperf test that compares for loops that iterate over an array with caching the array length condition vs not caching. I thought that caching the variable before to avoid recalculating the array length each iteration would be faster, but the jsperf test says otherwise. Can someone explain why this is? I also thought that including the array length variable definition (when cached) within the for loop's initialization would reduce the time since the parse doesn't need to look up the "var" keyword twice, but that also doesn't appear to be the case.
example without caching:
for(var i = 0; i < testArray.length; i++){
//
}
example with caching
var len = testArray.length;
for(var i = 0; i < len; i++){
//
}
example with caching variable defined in for loop initialization
for(var i = 0, len=testArray.length; i < len; i++){
//
}
http://jsperf.com/for-loop-condition-caching
Can someone explain why this is?
This optimization and case is extremely common so modern JavaScript engines will automatically perform this optimization for you.
Some notes:
This is not the case when iterating a NodeList (such as the result of querySelectorAll
This is an overkill micro optimization for most code paths anyway, usually the body of the loop takes more time than this comparison anyway.
The performance of the scenarios that you posted depends on how smart the JS engine's optimizer is. An engine with a very dump optimizer (or no optimizer at all) will likely be faster when you are using the variable, but you can't even rely on that. After all, length's type is well-known, while a variable can be anything and may require additional checks.
Given a perfect optimizer, all three examples should have the same performance. And as your examples are pretty simple, modern engines should reach that point soon.
Something is wrong with my code or with plovr. I went to JSLint to get some help. However, JSLint seems to consider this as a fatal error and refuses to check more of the code:
for (var i = 0; i < data.length; i += 4) {
Why? I like this way of declaring "I".
JSHint does not seem to be an alternative if you are on Windows. I am trying The Online Lint at the moment. I have a feeling that this bug will be a bit difficult to find so I would be glad for suggestions about good code checkers.
I agree with Niet the Dark Absol that the tool is opinion-based. Reflect on all the rules it imposes and whether they actually make sense in your specific project or not. It's also not the only "lint" tool for JavaScript. Maybe ESLint or another such tool is more suited to your needs.
But I also disagree with him: It is not good practice to declare all your variables at the start of your function, especially not if the function is rather long, since this makes comprehension of your program much harder. IMHO this holds regardless of how the scoping of JavaScript works: It's not about program semantics, it's about code readability!
I would argue that a variable should be declared as close to its first use as possible (i.e. in your case: in the for loop). This ensures that someone reading your code (a colleague or yourself three months from now) has too keep as little information in their head as possible. Declaring all your variables at the start forces the reader to keep all those variables in mind throughout the entire function. Questions like "what's the current value of this variable?" or "what is its purpose?" become harder to answer.
Furthermore, you are much more tempted to reuse a variable for more than one purpose. This is not only confusing, but also dangerous! Values might "leak" from the first use to the second. This can lead to subtle, hard-to-debug problems.
My personal opinion is that JSLint is retarded. But opinions may vary on that sensitive topic.
— dystroy, 45 secs ago
Hey, that's actually a valid point. JSLint is entirely constructed on opinion, and it not the word of god.
However, general good practice is to declare all your variables in one place, at the start of the function block they are in:
function doSomething() {
var a, b, c, d;
a = 1;
c = 10;
for( b = a; b < c; b++) {
d = b*2 + a-c;
alert(d);
}
}
Because creating a bar in the for loop creates a global var. it's one of those things that JavaScript does and most people don't realize. And if you don't and you or someone else creates that same var in the scope of that function or global scope then that my friend would be one of the famous JavaScript foot guns.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Lately I've been writing some JS code using jQuery and JavaScript as it is and I thought I will give JSLint a try. Let me say that the code contains various functions and jQuery usages and it works fine (without any errors ) in IE8 and latest Firefox.
The code also validatas as XHTML 1.0 Transitional (and Strict too but I mostly want it to be Transitional valid).
However, with JSLint it's like everything is wrong. While I have read about it being very strict, even if I turn on only "The Good Parts" it's still like 70+ errors in a typical HTML page.
It starts out with this (why in the world would I want to remove the type to make my documents XHTML invalid??)
Problem at line 5 character 67: type is unnecessary.
<script src="/Scripts/jquery-1.4.2.min.js" type="text/javascript"></script>
and goes on with esoteric errors like
Problem at line 41 character 41: Use the array literal notation [].
var rows = new Array();
Problem at line 42 character 30: Too many var statements.
for (var i = 0; i < data.length; i++) {
Problem at line 42 character 55: Unexpected use of '++'.
for (var i = 0; i < data.length; i++) {
Problem at line 64 character 50: ['PrettyId'] is better written in dot notation.
var item = $("#item_" + data["PrettyId"]);
If anyone can provide me answers to these errors and especially, how to make JSLint be aware of jQuery and understand it, I will appreciate it.
If not, please explain whether you use it or not and whether you advice to use it or not.
UPDATE:
I'm going to wait one more day for more answers, if any, then I'll accept the answer with the most upvotes.
A thing to remember when using JSLint is that is built on the opinion about what one person thinks is the "Good Parts".
I think is a great tool but there are rules that I don't agree with.
About the type attribute, you can find more about the opinion of the author here he says that the attribute is "required and non necessary", but if you validate your documents you clearly need it.
With the use of the Array literal notation [] vs. the Array constructor, I agree, there are differences that can make the two syntaxes behave different, for example:
[5]; // one-element array
["5"]; // one-element array
new Array(5); // empty array but its length is initialized with 5
new Array("5"); // one-element array
So, for consistency an brevity the literal notation is better.
About the "Too many var statements", JavaScript has no block-scope, the scope is at function or global level, and all var statements are evaluated before the code execution -aka hoisting- and they are initialized with undefined, while the assignments are made at runtime.
For example:
var x = 0;
if (true) {
var x = 1; // useless var, x already declared
}
x; // 1
And the "hoisting" of variable declaration can be shown in this example:
var x = 5; // global
(function () {
alert(x); // alerts `undefined`, x declared but unassigned in this scope
alert(y); // ReferenceError, y is undeclared
var x = 10;
})();
As you can see x holds undefined because it is declared before the actual code execution, the var statements are hoisted to the top of their enclosing scope:
var x = 5; // global
(function () {
var x;
alert(x); // alerts `undefined`, x declared but unassigned
alert(y); // ReferenceError, y is undeclared
x = 10; // assignment is made
})();
So that rule wants to actually make the code to resemble what will happen, all the var statements at first place.
About the "Unexpected use of '++'", this is another rule that I don't quite like, the author thinks that "those contribute to bad code by encouraging excessive trickiness".
When I use them in some expression, I try to extract the operator usage to an alone statement, for example:
array[++id] = x;
To:
id+=1;
array[id] = x;
Which is more clearer, but anyway in the case of a for statement IMO it can't cause any confusion at all...
About the last one "['PrettyId'] is better written in dot notation.", JSLint expects the usage of the bracket notation to be "dynamic", it expects to see an expression there, not a String literal that contains a valid identifier name, the bracket notation should be used only when you want to access a property with a name that clashes with a reserved word e.g.:
data.function; // SyntaxError in ECMAScript 3 based implementations
data["function"]; // Ok
Or when a property contains characters that are not a valid identifier, e.g.:
data.foo-bar; // it access the property `foo` minus a `bar` variable
data["foo-bar"]; // Ok
data.foo bar; // SyntaxError, unexpected `bar` identifier
data["foo bar"]; // Ok
I use jslint on .js files and find a combination of options and fixes to make it happy. I find it improves my code quality. I would recommend running it, even if you only use it to isolate omitted 'var' declarations.
I avoid the script tag warning by not running against html files. I use jslint systematically on .js files, but not on html. I find it is just too burdensome to declare all the global identifiers that got defined in included scripts, but aren't visible to jslint.
Crockford's book 'Javascript: The Good Parts' explains many if not all of the jslint warnings, and some of them are based on perceived bug proneness. The 'new Array()' vs ' []' warning is based on Doug's aversion to the 'new' operator. Omitting 'new' for various constructors is commonly valid code, but not correct code, and using the alternative syntax avoids that risk.
The 'too many vars' error means just that, a large number of 'var' declarations in a given function: the Crockford endorsed style is to use one or very few 'var' declarations, all at the top of the function. You can declare multiple variables in one var statement, by separating them with commas.
The '++' caution is another bug proneness based warning; Using '+=1' means the same thing, and Doug believes it to be less error prone.
jslint is thus a mixed bag. Some features (locals vs globals) are invaluable, some (script types) are just annoying, and many are of dubious benefit but harmless.
jQuery itself passes jslint checks, as described here:
http://docs.jquery.com/JQuery_Core_Style_Guidelines#JSLint
There's an old joke about a programmer who smoked. A friend said, "You're a really smart guy, can't you read the warning on the pack that says cigarettes will kill you?" Came the reply: "I'm a programmer. We only pay attention to errors, not warnings."
Sometimes JSLint tells you things that are critical, sometimes it just nags. You can get lost trying to make it happy, but you might just be lost without it. Like any other tool, its input should be taken with a grain of salt. I prefer to think of it like the spell-checker or grammar-checker in MS Word. Sometimes it's right, sometimes it's wrong, and sometimes I just don't care what it tells me.
It hurts when you start using it on your old code.
But then it will save you a lot of time.JSLint can detect many problems that you would only see when refreshing your page or worse when your users do.Now it hurts me when I have to use an editor without JSLint
Another advantage is when you start compressing your javascript. If you pass the JSLint checks, you are almost certain to compress without problems.
That being said, jquery has 23 warning, most of them about regex, but is widely used without any problems.
JSLint is a Code Quality tool. It's not like W3C validator. Consider it something like a weekly code review at a company. Coding conventions vary and JSLint is just one of them. There may be points you don't agree with, but if you work in a team and you need to manage a larger codebase JSLint can be a life saver. Why? Because it warns you about things that are confusing or error prone.
The best way to use JSLint is this: read everything it says and if you're unsure about something correct it as suggested (as it seems to be the case here).
The reason is that JSLint is meant to avoid confusion and if you're using something that can lead to errors and you don't know why, then you better off with a clear alternative.
And if you want to know the reasoning behind the suggestions watch Douglas Crockford's videos on Javascript.
Finally, you can turn off filters that you find useless.
you should use it. The fact that it works in one browser doesn't mean it will work in all browsers; some are more lenient than others. for example, having a trailing comma in an array will break in IE but work in FF.
Be aware that sometimes you get a ton of errors, but you remove the first and a dozen go away, like compiling code.
you can do
var rows = [];
for the first error.
Here are the best answers I can give. Perhaps someone can fill in some blanks. It doesn't appear as though any of these relate to jQuery, though.
Also, see this document for some explanations.
Problem at line 5 character 67: type is unnecessary.
<script src="/Scripts/jquery-1.4.2.min.js" type="text/javascript"></script>
and goes on with esoteric errors like
I believe that for modern browsers, there's no need for text/javascript when linking to external js files.
Problem at line 41 character 41: Use the array literal notation [].
var rows = new Array();
It is recommended to not call the constructor when creating an Object or Array. I'm honestly not sure why. Anyone?
Problem at line 42 character 30: Too many var statements.
for (var i = 0; i < data.length; i++) {
I suppose you have the i variable declared elsewhere in the same scope. A javascript block does not create scope, so if you have another for loop (for example) that uses i, it is using the same variable. No need to declare it again.
Problem at line 42 character 55: Unexpected use of '++'.
for (var i = 0; i < data.length; i++) {
Not sure about this one, except that if I recall correctly, Crockford doesn't like the ++ and --.
Problem at line 64 character 50: ['PrettyId'] is better written in dot notation.
var item = $("#item_" + data["PrettyId"]);
I believe . notation is preferred because it is shorter and faster (in some browsers anyway). So data.PrettyID instead.
As far as I can tell, nothing here appears to be explicitly wrong. Mostly just best practice advice from JSLint creator's perspective.