
Code Conventions for the JavaScript Programming Language - mshafrir
http://javascript.crockford.com/code.html
======
TNO
Some are good, some arbitrary:

Is the 80 col limit still valid in the modern day with such large screen
displays? . His line indentation convention is inconsistent. In one place he
says to use 8 spaces, in another he says to use 4. Then when you look at a
switch, its 0. . variable declarations: If he's referring to the way that
JSLint enforces it, that's stupid. ex:

    
    
        function foo(){
           myGlobal = "foo";
        }
    
        var myGlobal;
    

_"All functions should be declared before they are used"_

Yes, but not in the way that JSLint enforces it. See above.

 _"Inner functions should follow the var statement."_

umm, no? This has a different meaning from a function declaration.

 _"Do not use _ (underbar) as the first character of a name. It is sometimes
used to indicate privacy, but it does not actually provide privacy. "_

It's private because you weren't invited to use it, not because I have a bomb
waiting for you.

 _"If privacy is important, use the forms that provide private members. Avoid
conventions that demonstrate a lack of competence."_

Whatever, show me an efficient, non-convoluted pattern that allows inheritance
of privileged members. Avoid conventions that demonstrate a lack of concern
for memory consumption and efficiency.

 _"Global variables should be in all caps."_

umm, no. That convention is reserved for constants.

 _"Each group of statements (except the default) should end with break,
return, or throw. Do not fall through."_

Arbitrary. I think DRY is preferable when it's warranted.

 _"Avoid use of the continue statement. It tends to obscure the control flow
of the function. "_

It's ok to use labels, but not continue? I don't understand this logic.

 _"Avoid doing assignments in the condition part of if and while statements.
"_

It's a legitimate convention if wrapped with an extra pair of parenthesis.
Note that Mozilla's strict mode will honor this convention.

~~~
isleyaardvark
Few of the examples you listed are arbitrary, in fact Crockford describes
precisely why he chose them as conventions. In nearly all cases he came up
with these conventions to help coders avoid common pitfalls due to unfortunate
aspects of the JavaScript language.

    
    
        function foo(){
           myGlobal = "foo";
        }
    
        var myGlobal;
    

This is clear if you only have this one function, but with a large js file I
know I'd rather not be searching through the code for global variables. That's
also why "Inner functions should follow the var statement", it's an easy way
to keep track of scope.

 _"Do not use _ (underbar) as the first character of a name. It is sometimes
used to indicate privacy, but it does not actually provide privacy. "_ _It's
private because you weren't invited to use it, not because I have a bomb
waiting for you._

No, it's private because it throws an error if you try to use it outside of
the proper scope. From what I can tell about Python, for example, adding
underbars enforces privacy, JavaScript doesn't.

 _"Global variables should be in all caps."_ _umm, no. That convention is
reserved for constants._

That convention _in other languages_ is for constants. Crockford points out
that js doesn't have constants. He also constantly points out the dangers of
global variables, how you should minimize their use. The purpose of all caps
is to give a visual cue that they're global, the purpose of all caps in other
languages is to give a visual cue that they're constants.

 _"Each group of statements (except the default) should end with break,
return, or throw. Do not fall through."_ _Arbitrary. I think DRY is preferable
when it's warranted._

Crockford used to think the same. He tells the story of a user who suggested
fall-through should be flagged by JSLint. Crockford gave him a detailed
response explaining that there was nothing wrong with fall-through. The user
agreed, and included a bug report for JSLint in his response. Crockford found
the bug in JSLint and it was caused by... fall-through.

 _"Avoid doing assignments in the condition part of if and while statements.
"_ _It's a legitimate convention if wrapped with an extra pair of parenthesis.
Note that Mozilla's strict mode will honor this convention._

Crockford points out the problems you can run into doing that:

Is

    
    
        if (a = b) {
    

a correct statement? Or was

    
    
        if (a == b) {
    

intended?

It's easy enough to tell if you're the one who wrote it, but what happens to
the poor sorry schlub who's trying to debug the code later on (especially if
that schlub is you 6 months later)?

~~~
unwind
_From what I can tell about Python, for example, adding underbars enforces
privacy, JavaScript doesn't._

That's not true, an initial underscore is simply used as the convention to
indicate that something is private:

    
    
        >>> class Foo(object):
        ...   def __init__(self):
        ...    self._bar = 48
        ...
        >>> a=Foo()
        >>> a._bar
        48

~~~
mdg
Au contraire, double underscore does make it "private". Trying to access a
double underscore attribute directly will throw an AttributeError.

    
    
        >>> class Foo(object):
        ...     def __init__(self):
        ...             self.__a = 42
        ...     def look_here(self):
        ...             print self.__a
        ...
        >>> f = Foo()
        >>> f.__a
        Traceback (most recent call last):
          File "<stdin>", line 1, in ?
        AttributeError: 'Foo' object has no attribute '__a'
        >>> f.look_here()
        42

~~~
tkaemming
A bit off topic, but double underscores don't actually make members in Python
truly private, but mangles the attribute name to prevent you from accessing it
unless you _really_ need to:
[http://docs.python.org/tutorial/classes.html#private-
variabl...](http://docs.python.org/tutorial/classes.html#private-variables)

    
    
        >>> class Foo(object):
        ...     def __do_something(self):
        ...         print 'something was done'
        ... 
        >>> f = Foo()
        >>> f.__do_something()
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
        AttributeError: 'Foo' object has no attribute '__do_something'
        >>> f._Foo__do_something()
        something was done

~~~
mdg
You are 100% correct.

This is a good example of Python making it harder for you to do the wrong
thing. Sure.. you could access that "private" attribute, but you have to do it
in a way that isn't obvious, and definitely more hard to read.

------
bajsejohannes
There are arguments for and against tabs and spaces. Crockford mentions one of
these arguments and concludes that everyone should use spaces. Similarly for
other "conventions".

I would rather replace the whole article with "Write readable code". Following
these conventions are neither sufficient or necessary to accomplish that.

~~~
gjm11
1\. The people for whom "Write readable code" is sufficient guidance are the
same people for whom that guidance isn't needed in the first place.

2\. For a body of code written by multiple people to be readable, it helps
considerably if the conventions those people follow are consistent. A document
like this one can help with that.

3\. It doesn't seem reasonable to expect that the author of a document like
this should provide all the counter-arguments to every position he takes. It's
not an in-depth analysis of what constitutes good JavaScript code, it's just a
set of coding conventions.

~~~
abstractbill
_For a body of code written by multiple people to be readable, it helps
considerably if the conventions those people follow are consistent._

I'm not convinced of this (at least it doesn't hold true for me). I _used_ to
believe it, mostly because it seems to be common wisdom. But I've realized
over time that I can just as easily read code that's written using K&R style
braces, or BSD style, or even Whitesmiths, and it really doesn't matter to me
whether indentation is 2, 4, or 8 spaces.

I think some of my point of view comes from being a heavy Emacs user and
having written a lot of Lisp code in the past. I don't tend to _see_
braces/parens much for example - I let the editor take care of them.

~~~
nostrademons
I can easily read code that's written with 2, 4, or 8 space indentation. I
can't read code that's written with 2, 4, or 8 space indentation _at the same
time_.

The most important part about code conventions is that you have them. It
really doesn't matter what they are. In fact, I wish fewer styleguides would
pretend to be _right_ and more would just acknowledge that they're simply
whatever the originator prefers. But it's still very important that everyone
agrees to follow them, even if they disagree with some of the individual
aspects.

------
draegtun
Unsurprisingly not too different from Perl Best Practices by Damian Conway
(ref card: [http://refcards.com/docs/vromansj/perl-best-
practices/refgui...](http://refcards.com/docs/vromansj/perl-best-
practices/refguide.pdf)).

But one difference I noticed was the use of "cuddled" else in Crockford's
list:

    
    
        } else {
    

instead of PBP's:

    
    
        }
        else {
    

Conway believes this is more readable and inline with K&R style (used in both
conventions/practises).

------
nixy

      "Avoid lines longer than 80 characters."

This one really bugs me. 80 characters doesn't fit a whole lot of stuff. In a
case where a line is more than 80 chars long I would rather see this:

    
    
      document.getElementsByClassName("externalLinkBig")[0].setAttribute("class", "externalLinkSmall");

than this rather ugly solution:

    
    
      document.getElementsByClassName("externalLinkBig")[0].setAttribute("class", 
            "externalLinkSmall");

~~~
nimbix
Personally, I find both examples from your post rather unreadable. I always
chain method calls like this:

    
    
        document
            .getElementsByClassName("externalLinkBig")[0]
            .setAttribute("class", "externalLinkSmall");

~~~
axod
That's ugly (IMHO) and not a good idea in js where semicolons are optional...

For all we know it may execute 'document' as a statement, and then the next
lines.

Not nice IMHO

If you can fit 160 chars on the display, use 160.

------
mmb
Some of this contradicts jslint with "The Good Parts" options. It will
complain about multiple var statements and missing space after function.

