David said:
Martin said:
I have added the "Dojo Style Guide" to my conventions compilation,
here:
http://www.MartinRinehart.com/articles/javascript-conventions.html
The Dojo document is more comprehensive than Crockford.
But is it useful advice? After all, it was written by the authors of
Dojo.
[snip]
An excerpt:
"Names representing types (classes) MUST be nouns and written using
CamelCase capitalization:
Account, EventHandler"
What?!
You need to translate that with scriptkiddie.sed first:
s/Names/Identifiers/
s/types (classes)/constructors/
Then it makes sense and I can only second it (and have done so before).
One common JS/ES beginner's mistake is to confuse primitive data types and
constructors and prototype objects because in other languages, particularly
Java, each constructor is related to a class which is considered a type of
its own.
Not so in implementations of ECMAScript until including Edition 3:
a user-defined constructor, e.g.
function Foo()
{
}
refers to a *Function* object (which could be said to be of type "function"
since that is what the `typeof' operation applied on it yields), and objects
created using this constructor with e.g.
new Foo()
are, strictly speaking, (possibly augmented) *Object* objects (however, I,
too, tend to use the shortcut term "Foo object" instead, for the lack of a
better, equally concise term). In any case, the typeof operation on them
yields "object", so they could said to be of that type.
It would also appear that the ECMAScript Language Specification itself
supports misunderstanding as it defines e.g. a (primitive) "String type"
[section 8.4], a String() function that converts to the "String type"
[15.5.1], and a String() constructor that creates a "String object"
[15.5.2]. This ambiguity is hard to understand particularly for beginners,
and one can only hope that Brendan Eich's suggestion on how to fix it will
eventually be part of the next edition of ECMAScript (3.1/4).
PointedEars
