By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,362 Members | 1,337 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,362 IT Pros & Developers. It's quick & easy.

Updated Conventions Document

P: n/a
I have added the "Dojo Style Guide" to my conventions compilation,
here:

http://www.MartinRinehart.com/articl...nventions.html

The Dojo document is more comprehensive than Crockford.

Unless someone objects, I'm going to take their odd statement
formatting out and just make note of it briefly, in the interest of
shrinking my compilation.
Nov 5 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On Nov 5, 2:30*pm, Martin Rinehart <MartinRineh...@gmail.comwrote:
I have added the "Dojo Style Guide" to my conventions compilation,
here:

http://www.MartinRinehart.com/articl...nventions.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?!
Nov 5 '08 #2

P: n/a
David Mark meinte:
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?!
I've another one for you - enjoy:

http://jsdoc.sourceforge.net/#tagref

Ain't that nifty? By throwing in JSDoc JS suddenly knows "classes"
subclasses "extending" superclasses, "private" classes, "members" of
classes, class dependencies, etc.

Gregor
Nov 5 '08 #3

P: n/a
On Nov 5, 6:40*pm, Gregor Kofler <use...@gregorkofler.atwrote:
David Mark meinte:
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?!

I've another one for you - enjoy:
In what sense?
>
http://jsdoc.sourceforge.net/#tagref
Ah, you were making a joke. I hadn't heard that one before.
>
Ain't that nifty? By throwing in JSDoc JS suddenly knows "classes"
subclasses "extending" superclasses, "private" classes, "members" of
classes, class dependencies, etc.
Pure genius. It is like they made it a whole new language. Those
guys should write a library! :)
Nov 6 '08 #4

P: n/a
David Mark wrote:
Martin Rinehart wrote:
>I have added the "Dojo Style Guide" to my conventions compilation,
here:

http://www.MartinRinehart.com/articl...nventions.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
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Nov 6 '08 #5

P: n/a
On Thu, 6 Nov 2008 at 19:17:27, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>David Mark wrote:
>Martin Rinehart wrote:
>>I have added the "Dojo Style Guide" to my conventions compilation,
here:

http://www.MartinRinehart.com/articl...nventions.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).
<snip>

An identifier is a syntactic unit : a string that obeys certain rules.

A name need not be an identifier. For instance, some people want
properties with names such as items[] .

You could have pointed out that EventHandler is not a noun, it's a noun
phrase.

John
--
John Harris
Nov 11 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.