6 ms·

Code Conventions for the JavaScript Programming Language

31 points by mshafrir 17y ago

bajsejohannes 17y ago
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.
- asjo 17y ago
  There are arguments for and against tabs and spaces. ... and if you don't want to rehash those arguments, jwz has a nice summary: http://www.jwz.org/doc/tabs-vs-spaces.html http://www.jwz.org/doc/tabs-vs-spaces.html
  - sesqu 17y ago
    I found that summary wholly unconvincing, and very disparate from how I might summarize the arguments. I guess that's just how these things go.
- gjm11 17y ago
  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 17y ago
    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.
    - Legion 17y ago
      In terms of reading a complete body of code in one style or another, I agree. What is annoying and distracting is having conflicting styles in the same single chunk of code. Sort of like how I would not want a book to randomly change line spacing, character spacing, etc. from paragraph to paragraph. I don't really care what the spacings are, and I certainly have no problem going from one book to another where these are totally different, but I do not want them flip-flopping around in the text of a single book.
    - nostrademons 17y ago
      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.
nixy 17y ago
"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 17y ago
  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 17y ago
    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.
- thenduks 17y ago
  How about: document .getElementsByClassName( 'externalLinkBig' )[0] .setAttribute( 'class', 'externalLinkSmall' ); 80 columns is definitely my preferred (but not "I'll complain") line length because I don't have my editor maximized (cringe) and long lines aren't as easy to read (especially when there's several long lines in a row, it's hard to keep them straight near the far right).
- jayair 17y ago
  Yeah chaining is a way to do it. I've recently gotten addicted to chaining though. So now a lot of my functions look like this. A listener for the timespan navigation that Cadmus has: 'onNextTimespanClick': function(e, el) { return this .onNavigationClickStopEvent(e, el) .scrollToTop() .animateNavChange( this.getSelectedNavigationEl(), $$( 'div.navigation a[href=' + this.getHashFromUrl(el.href) + ']', this.navigationContainer ) ) .refreshItems(); },
TNO 17y ago
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.
- maigret 17y ago
  About the 80 lines width: yes, and it is much more important now than never (in my opinion). Have a look at most news websites, or at a normal book, or a newspaper, or LaTeX (and even Word!) standard text-width, it's all fitting in around that size because it is very efficient to read. Unlimited width for text is a UI anti-pattern, as the eye gets more and more pain to find the next line. A great example of site respecting the 80 chars rules is Paul Graham's essays site, reading it is a pure pleasure also because of the fine presentation.
  - 17y ago
draegtun 17y ago
Unsurprisingly not too different from Perl Best Practices by Damian Conway (ref card: http://refcards.com/docs/vromansj/perl-best-practices/refguide.pdf http://refcards.com/docs/vromansj/perl-best-practices/refgui...). 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).
mmb 17y ago
Some of this contradicts jslint with "The Good Parts" options. It will complain about multiple var statements and missing space after function.

31 points by mshafrir 17y ago

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.

asjo 17y ago
There are arguments for and against tabs and spaces. ... and if you don't want to rehash those arguments, jwz has a nice summary: http://www.jwz.org/doc/tabs-vs-spaces.html http://www.jwz.org/doc/tabs-vs-spaces.html
- sesqu 17y ago
  I found that summary wholly unconvincing, and very disparate from how I might summarize the arguments. I guess that's just how these things go.
gjm11 17y ago
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 17y ago
  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.
  - Legion 17y ago
    In terms of reading a complete body of code in one style or another, I agree. What is annoying and distracting is having conflicting styles in the same single chunk of code. Sort of like how I would not want a book to randomly change line spacing, character spacing, etc. from paragraph to paragraph. I don't really care what the spacings are, and I certainly have no problem going from one book to another where these are totally different, but I do not want them flip-flopping around in the text of a single book.
  - nostrademons 17y ago
    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.

nixy 17y ago

"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 17y ago
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 17y ago
  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.
thenduks 17y ago
How about: document .getElementsByClassName( 'externalLinkBig' )[0] .setAttribute( 'class', 'externalLinkSmall' ); 80 columns is definitely my preferred (but not "I'll complain") line length because I don't have my editor maximized (cringe) and long lines aren't as easy to read (especially when there's several long lines in a row, it's hard to keep them straight near the far right).
jayair 17y ago
Yeah chaining is a way to do it. I've recently gotten addicted to chaining though. So now a lot of my functions look like this. A listener for the timespan navigation that Cadmus has: 'onNextTimespanClick': function(e, el) { return this .onNavigationClickStopEvent(e, el) .scrollToTop() .animateNavChange( this.getSelectedNavigationEl(), $$( 'div.navigation a[href=' + this.getHashFromUrl(el.href) + ']', this.navigationContainer ) ) .refreshItems(); },

TNO 17y ago

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.

maigret 17y ago
About the 80 lines width: yes, and it is much more important now than never (in my opinion). Have a look at most news websites, or at a normal book, or a newspaper, or LaTeX (and even Word!) standard text-width, it's all fitting in around that size because it is very efficient to read. Unlimited width for text is a UI anti-pattern, as the eye gets more and more pain to find the next line. A great example of site respecting the 80 chars rules is Paul Graham's essays site, reading it is a pure pleasure also because of the fine presentation.
- 17y ago

draegtun 17y ago

Unsurprisingly not too different from Perl Best Practices by Damian Conway (ref card: http://refcards.com/docs/vromansj/perl-best-practices/refguide.pdf http://refcards.com/docs/vromansj/perl-best-practices/refgui...). 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).

mmb 17y ago

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