We Keep Coding

JavaScript syntax highlighting -- is status a keyword? -- what's it used for?

My vim syntax highlighting just lead me to believe that status is a keyword in JavaScript.
Searching around all I can find are articles about window.status in browser JavaScript. Is this the meaning of this 'keyword' status or is there something different going on?
What is the keyword status?

This answer is actually incorrect. I probably confounded static with status. The Mozilla website has a page about the window.status. It may have been done that way so you do not try to use that name as a variable. That way you would not inadvertently update the status bar of your browser. The feature doesn't work anymore, but I guess the in editors is lagging.
In the Mozilla documentation (which is easier to read than the ECMA reference,) we find the status keyword under the Future reserved keywords section.
So, it is viewed as a keyword.
However, JavaScript accepts reserved keywords in various places such as after a period as in:
a = {}
a.default = 123
a.status = 555
Here I set the default and status members of object a even though these two names are viewed as reserved keywords in the language.
Actually, if you have been using Promise objects, you may have noticed the catch keyword used as one of the possible callbacks:
Promise.all([a, b, c])
.then(...)
.catch(...) <-- this is a reserved keyword
.finally(...) <-- this is a reserved keyword
Here are the pertinent grammar entries:
Identifier :
IdentifierName but not ReservedWord
MemberExpression :
PrimaryExpression
MemberExpression [ Expression ]
MemberExpression . IdentifierName <-- look at this one
MemberExpression TemplateLiteral
SuperProperty
MetaProperty
new MemberExpression Arguments
An IdentifierName is any identifier (more or less [A-Z_$][A-Z_0-9$]*, plus all Unicode characters... they actually follow the Unicode definition of an identifier.) That includes reserved keywords.
As we can see, you are not supposed to start an expression with a ReserverWord, except for a new exception like new and super (not shown here, see SuperProperty.)
So in strict mode (i.e. in a node module) you should get an error if you write:
status = 123
In non-strict mode, status is not a reserved keyword and therefore it is allowed.
One way to make sure that it works when you access variable members is to use the array syntax. For example:
a['default'] = 123
a['status'] = 555
Also that way the names do not get highlighted as reserved keywords by your editor.

If you play around in your console. You can do the following:
-> status
<- ""
-> window.status
<- ""
-> status='333'
<- "333"
-> status
<- "333"
-> window.status
<- "333"
This to me indicates that the keyword status is simply an alias for the window.status property. What exactly window.status does I am not sure.
EDIT: After reading the comment below, I realized that properties of the windows object are essentially global. So this makes status the same as window.status and NOT an alias as I mention above.
See this Stack Overflow about the window object:
Is window really global in Javascript?

Javascript - Why use string as function name

I'm working on a dojo project and stumbled on code below:
format: function ( /*Date*/ value, /*locale.__FormatOptions*/ constraints) {
....
},
"parse": function ( /*String*/ value, /*locale.__FormatOptions*/ constraints) {
.....
},
As you can see parse method name is a string. I haven't seen something like this before. Is there any reason for doing this?
Link to original file.

According to JavaScript / ECMAScript standard, object property (or functions) identifiers (as used before the colon : in your example) can be any valid identifier (i.e. like the format without quotes), any string (like "parse") or even any number.
Using "parse" in that case is strictly equivalent as using parse, but that would have been different in the case for example of "parse that value", which is a valid string identifier for an object property, even though it has spaces!
Then you can use either myObject.parse or myObject["parse"] to access your property, whereas in my last example you have no choice but using myObject["parse that value"] to access it.
I think we should also mention a specific case where using quotes for object keys is different from without quotes: if you were to use Google Closure minifier in ADVANCED_OPTIMIZATIONS mode, it would replace any non-quoted identifier to try and save space, whereas it would leave intact quoted identifiers, as Google team took this as the indicator that you will try to access it later on with the square brackets method and string, or if you check the actual key name like this:
for (var i in myObject) {
if (i === "parse") { // if i is replaced by the minifier, you will never execute the block below
// do something...
}
}
This specificity which forces you to use quoted identifiers sometimes (but not always, if you do not need to keep the original name) is one of the reasons that push people not using this advanced optimizations mode.

I don't see any reason for using extra quotes.
JSON requires it, but your object literal is not JSON. ES3 required this for keywords, but parse never was a keyword.

In this particular case there is no reason to do that, but I've faced scenarios where I needed to use quotes to define elements. For example:
var httpHeadersToAdd= {
'User-Agent': 'whatever',
Date: new Date()
};
With no quotes the interpreter understands that your are trying to do a subtract operation with variables User and Agent and throws a syntax error SyntaxError: Unexpected token -. Same can be made with functions, and then you have to call them with brackets:
var obj= {
'my-function': function (){}
}
obj['my-function']();
Going back to the code you linked, maybe someone wrote that in a JSON-ish way because that's how JSON strings looks like (double quotes are mandatory in JSON, single quotes don't work)

Why is object with duplicated property accepted in JavaScript?

I was expecting JavaScript to reject objects with duplicated properties as invalid but it accepts them in some cases.
{"a":4,"a":5} results in an SyntaxError at least in Firefox and Chrome which seems obvious due to the property a being defined twice.
However ({"a":4,"a":5}) evaluates just fine and results in an object {"a":5} in both Firefox and Chrome.
Why is the expression with the parenthesis accepted?
Summing up the responses: The first example is simply not the construction of an object but a block of labeled statements. Duplicated properities in objects are perfectly valid in which case the last definition wins.
Thanks a lot for your answers!

It is perfectly legal in ECMAScript 3 to declare duplicate properties in an object literal; the SyntaxError you get probably comes from the fact that you used an object literal as a statement, which is not possible due to the confusion with block statements ({ doSomething(); }).
If you want this to be reported as an error, you may want to switch to ECMAScript 5's strict mode: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and_function_scope/Strict_mode.

What you state has no problem if you assign it to a variable, if you don't however, you get the error you mention. Which makes all the difference from a syntax point of view.
When you wrap any structure in parens you are causing that syntax to be evaluated as an expression, the result of which is stored as a temporary variable. The error I get when not doing so in Firefox is unexpected label or invalid label, so it seems without assignment, or parens, this object construction is not treated as an object construction - instead it is treated as a block with multiple label statements that are defined illegally:
{
a: function(){
alert('a');
},
b: function(){
alert('b');
}
}
The above should be totally acceptable as an object, however you get a similar error if you evaluate it without assinging it to some form of variable, or evaluating it with parens. Put simply the duplication of the attribute name is not causing the error :)
Basically imagine your first example, but like this:
function (){
"a": 4,
"b": 5
}
That is roughly how these browsers are treating it, which is now obviously illegal javascript syntax... whereas it wasn't so obvious before.

In the first notation (parentheses-less) the javascript syntax is ambiguous. From ecmascript specification:
An ExpressionStatement cannot start with an opening curly brace
because that might make it ambiguous with a Block.
A block basically evaluates all the statements inside, equivalent to evaluating "a":4,"a":5 which is not valid JS and, in fact, returns the same SyntaxError Unexpected token :
Wrapping that code in parentheses (or, rather, a grouping operator) removes that ambiguity since an assignment expression cannot be followed by a block statement:
var test = {"a":"a","a":"b"}; //test.a === "b"
Furthermore this ambiguity can be removed by any operator or expression that cannot be used with a block statement. A practical scenario hardly comes to mind, maybe if you wanted to return an object literal as part of a conditional operator?
//this *could* come out of a JS minifier:
return x ? (foo(),{"a":"b"}) : (bar(), {"b":"a"});

Why should it not be accepted? You're simply overwriting the values. I think it's rather a feature, than an error. And it works fine for me on various browsers: http://jsbin.com/oculon/1/edit
It's like writing
var a;
a = 4;
a = 5;
alert(a);

it's not Error you just overwrite value with another

I'm guessing (though not certain) that this evaluates as an error because of the difference between the way Firefox and Chrome's JS parsers treat statements and expressions. So because it's wrapped in parentheses the second time, it's considered an expression. Since it's looking for less information in an expression, it can ignore erroneous values. You'll see that if you do...
var a = {'a': 5, 'a': 4};
console.log(a);
It works fine! And also notice that here it's in the right hand side of the statement, giving a hint that it's an expression.

Using reserved words as property names, revisited

Can a reserved word be used as an object's property name?
This issue was raised indirectly in a previous Stack Overflow question: Browser support for using a reserved word as a property name in JavaScript. The answer seemed general consensus by Alex Wayne:
You can use those words, but only as strings and not shorthand
properties.
foo['class']; // cool
foo.class; // not cool
While I think that they are probably more knowledgeable than me in this area and it is probably a bad idea to use reserved words in some situations, I think their conclusion is wrong based on two points:
testing of the reserved words using them as a "shorthand" properties
the HTMLFormElement makes it impossible not to use reserved words in "shorthand"
First, using the reserved word list, each was added as a property to an Object and HTMLElement, both as obj["word"] and obj.word, and then retrieved as obj["word"] and obj.word. In each of the 63 cases all eight tests worked correctly.
Second, the HTMLFormElement necessitates this works because it retrieves in its elements using shorthand notation. If <input name='typeof' value='scalar' /> is an element of a form, then form.typeof == "scalar".
From my experience, reserved words are usually data inflicted (e.g. a column named "private"), not program inflicted. As such they contaminate JSON objects, and from there input, and from there the HTMLFormElement. Simply put, without a huge amount of (IMHO unnecessary) work, it's impossible to keep reserved words not being forced to work correctly in shorthand.
It seems to me these real problems:
care needs to be taken not to conflict with existent properties, not reserved words
(many if not all) variables cannot be reserved words
use of reserved words as properties can be (but are not necessarily) confusing
Is this conclusion correct then, that reserved words as property names, and accessing them either as strings or shorthand, is just fine - as long as a little common sense is applied to the situation?

In ECMAScript, starting from ES5, reserved words may be used as object property names "in the buff". This means that they don't need to be "clothed" in quotes when defining object literals, and they can be dereferenced (for accessing, assigning, and deleting) on objects without having to use square bracket indexing notation.
That said, reserved words may still NOT be used as identifier names. This is stated quite unambiguously in the spec and is stated somewhat emphatically here (if you don't want your eyes to bleed by having to read the actual language spec)...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Reserved_Words
The following are keywords and may not be used as variables,
functions, methods, or object identifiers, because ECMAScript
specifies special behavior for them:

I'm not quite sure what the point is you want to make, so the only answer I can give is: Yes, it's ok to use reserved words as property names.
(However two small remarks: foo["class"] is ok, not foo[class]. And any way you should be using form.elements["xyz"] and not form.xyz to access an element named xyz.)

Yes, it can be used.
Just small remark, if you use YUI compressor you have to put property name which is equal to one of js reserved words in quotes.
For example, this won't compress
var a = { case : "foo"}; // syntax error, "invalid property id"
a.for = "bar"; // syntax error, "missing name after . operator"
This will do
var a = { "case" : "foo"}; //OK
a["for"] = "bar"; //OK
Here is Online JavaScript/CSS Compression Using YUI Compressor where this can be tested.

Yes, in most browsers (including IE9+)
There's actually an entry in the Kangax compatibility table for "Reserved words as property names"
http://kangax.github.io/compat-table/es5/#test-Object/array_literal_extensions_Reserved_words_as_property_names

Does it make any sense to use JSLint and follow it? [closed]

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.