permalink

68

JavaScript Style Guides And Beautifiers

Today we're going to explore JavaScript style guides, specifically: their importance, style guides worth reviewing and tools that can assist in automated code beautification or style enforcement.

What exactly is a style guide?

Before we begin, let us remind ourselves exactly what a code style guide is:

A style guide or style manual is a set of standards for the writing and design of code. The implementation of a style guide provides uniformity in code style and formatting, often covering guidelines regarding indentation (tabs vs. spaces), variable and function naming conventions, where best to apply whitespace and so on.

Why is consistent code style important?

They say that good code is it's own documentation. Whilst I don't completely agree with this (docs are important!), the fact is, the more readable our source code is, the easier it is to maintain.

Following a consistent style guide both helps enforce this concept and improves the overall quality of the code we write. This facilitates other developers stepping in to assist with maintenance more easily and can certainly save time in the long haul.

Readable source code is arguably easier for us to understand as well. It's easier to browse, locate and fix bugs in and more easy to optimize. It can also give us a clearer picture of how the code fits into a larger body of work. This is not to say that poorly styled code is badly written code. Indeed, I've seen several cases of code which were styled quite poorly, but were in fact, very efficiently written solutions on the whole.

Consistently styled code can:

  • Reduce the lead time required to understand an implementation
  • Make it easier to establish what code can be reused
  • Clarify how updates to an implementation should be styled or structured (remember that consistent code, even when written by a team, should look like one person wrote it).

Are developers really using style guides in practice?

Advocating for the use of style guides is great, but it doesn't mean a great deal if only 1% of developers are seriously considering using them. To get a better gauge on this, I did an informal survey on Twitter, asking developers whether they were using a style guide for the JavaScript they were writing.

I received a relatively good sampling responses, below of which are a few:

  • Rodney: Pretty much the jQuery style guide – just without the insane amount of whitespace
  • Sindre: Idiomatic.js of course, with single-quotes and tab indention
  • D.Cherman: There's no precedent in my group, but I'm pushing towards following the guidelines in idiomatic.js
  • Marek: I use Crockford's style all the time, unless I'm contributing to a project that doesn't
  • Jack: I use my own JS style guide, which essentially is a mash up of all the popular ones out there, very similar to them too
  • Matt: Yes (based on jQuery and Idiomatic) but so long as projects are consistent then I'm flexible
  • Jamie: I'd use an existing one in a team I was joining, or propose we agree on a standard if 1 wasn't in place. Happy with any style at all, just as long as there is one – so it reads like one person wrote it all. Just my opinion.
  • Arthifiji: At work we are planning to use coding and style guides from Google. We have found it to be very comprehensive

Recommended JavaScript Style Guides

For developers interested in improving the code style consistency of the JavaScript they write, I'm happy to recommend the following style guides:

  1. Idiomatic.js. This is not only highly recommended and very comprehensive, but is also the style guide we've adopted for several of the projects I'm involved in. It includes contributions by jQuery core contributor Rick Waldron, jsPerf contributor Mathias Bynens and many other experienced JS devs in the community. Not all developers agree 100% with the practices it advocates, but that's the great thing about a forkable style guide – it's easy to adapt to your own needs.

  2. jQuery Core Style Guide. Perhaps the most popular style guide modern JS developers are aware of, it is used by the jQuery core team, jQuery UI, QUnit and many other projects. Rick Waldron once again had a hand in this as have Adam Sontag and John Resig, also of jQuery fame.

  3. Google JavaScript Style Guide. Written by former Google JavaScript developers such as Robby Walker (Closure Linter), this contains several readability best practices that those from a particularly traditional software engineering background will appreciate. Further comments on it can be found here.

  4. Dojo Style Guide Another very comprehensive alternative by the people that brought us the excellent dojo toolkit. Interestingly this guide is based on the structure of the Java programming conventions guide. If you like what you see, you might also appreciate dojo's inline documentation sguide, which remains my favorite style of inline commenting in JS.

  5. Aloha Editor JavaScript Style Guide This guide comes from the authors of the relatively non-trivial contentEditable-based Aloha Editor. Whilst it recommends the jQuery style guide, it has some useful (minor) additions such as how they suggest styling AMD modules.

  6. Crock's Code Conventions For JavaScript Another good guide, although perhaps not as detailed example-wise as others. I feel this has been superseded by Idiomatic.js, but if you strongly disagree with it or the jQuery core style guide, this is a much recommended fallback.

As two developers mentioned using the NPM style guide for their projects, I'll mention it in passing. Designed with reducing visual clutter in mind, this minimalist guide does contain similar practices to those seen in other guides above but is probably what I would consider a 'light' set of guidelines. The recommendations in 1-6 should definitely be considered more comprehensive.

Note: I've reviewed all of the above and discarded some other guides that were either entirely too brief/vague or (in my opinion) not that useful at all (e.g the GitHub JavaScript style guide).

A Tutorial On Applying The Principles Of Idiomatic Code Style

Let's go through a brief tutorial. Here is a functional block of code that doesn't follow any particular guidelines on code style:

function foo(bar,baz,fum){

    var hello = "Hello";
    var ret;
    var num = 1;

    for(var i = 0; i < bar.length; i++) {
        var out = bar[i];
        if (out === ""){
            ret = fum(out) + baz(out);
        }
    }

    if (!(ret == undefined)) {
        return ret;
    } else{
       return fum('g2g');
    }

}

There's technically nothing wrong with it that would prevent it from running, but it could certainly be improved.

In order to better appreciate the impact of a consistently readable code style, let's go through this sample line-by-line and compare how it would look if we were to apply the Idiomatic.js style guide to it.

We will compare what the code looks like before and after it's been stylized and I've added notes in case it isn't clear on first glance.

1.Named function declarations

Before:

function foo(bar,fum,baz){

After:

function foo( bar, fum, baz ) {

What changed? We improved readability by:

  • Forcing consistent spacing before each of the arguments
  • Ensursing this accounts for a space after the function's opening bracket and before the closing bracket
  • Adding a space between the closing bracket and the opening brace of the next block

2.Variable assignments

Before:

    var hello = "Hello";
    var ret;
    var num = 1;

And we also had inline variables in our for loop:

for(var i = 0; i < bar.length; i++) {
    var out = bar[i];

After:

    var ret,
        out,
        hello = "Hello",
        num = 1,
        i = 0,
        l = bar.length;

What changed?

  • We moved to using one 'var' per functional scope to promote readability. As the Idiomatic guide states, this allows our declaration list to be more free of clutter
  • We moved the inline 'var' declaration for i from inside our loop to this same list. bar.length was cached in this same list under a variable l to avoid having to recalculate the length of bar each time. 
  • We moved the 'var' declaration for out to this list. This follows the idea of only declaring new vars once in our scope

3.Loops:

Before:

for(var i = 0; i < bar.length; i++) {

After:

for ( ; i < l; i++ ) {
    out = bar[i];

What changed?

  • Consistent whitespace is now used throughout the loop definition
  • Specifically this is done (i) after the for keyword and prior to the opening bracket, (ii) between each expression/statement within the loop and (iii) prior to our opening brace
  • By setting our pointer i to 0 prior to the loop, we can avoid the need to define this inline.Instead a simple semi-colon can be used in it's place, which some developers argue reduces clutter. Note: Hoisting the counter declaration to the top of the function is only a stylistic choice here and can be avoided if you feel uncomfortable with it. I personally would usually keep it inline to avoid detracting meaning.

4.Conditional evaluation:

Before:

        if (out == ""){
            ret = fum(out) + baz(out);
        }

After:

        if ( !out ) {
            ret = fum( out ) + baz( out );
        }

What changed?

  • Rather than evaluating out is empty, we can instead evaluate falsy-ness instead (i.e !out). This both requires fewer keystrokes and is arguably more readable
  • As in previous examples, liberal whitespace is used to surround arguments being passed to functions as this is easier on the eyes

5. Practicality – More on conditional evaluation

Before:

    if (!(ret == undefined)) {
        return ret;
    } else{
       return fum('g2g');
    }

After:

return ret || fum('g2g');

What changed?

  • We're no longer relying on the less reliable == (which should really have been === anyway)
  • !(ret == undefined) could be rewritten as !(ret) to once again, take advantage of falsy-ness (but this can be further improved)
  • Rather than opting for any of the verbose options above, we can take advantage of the fact that in an or expression, ret (if undefined or false) will skip to the next condition and use it instead. This allows us to trim down our 5 lines of code into fewer characters and it's once again, a lot more readable

Our final product:

function foo( bar, baz, fum ) {

    var ret,
        out,
        hello = "Hello",
        num = 1,
        i = 0,
        l = bar.length;

    for ( ; i < l; i++ ) {
        out = bar[ i ];
        if ( !out ) {
            ret = fum( out ) + baz( out );
        }
    }

    return ret || fum('g2g');
}

Note: I'm aware there is much more that can be done to improve the original code sample. A proper solution would include type checking against bar, baz and fum (and more), however for tutorial purposes, I wanted to focus on styling the core concepts.

Recommended JavaScript Beautifiers

Whilst maintaining consistent style while writing your code is extremely important, it can also be useful to use a formatter or beautifier to enforce style rules for you.

Google Closure Linter

Malte Ubl recently suggested that I try out Google Closure Linter. This set of useful Python scripts first allow us to lint our JavaScript against the Google JavaScript Style Guide, outputting a list of syntax and semantic changes needed to make our code Style-guide compatible. Users of tools like jsLint and jsHint will find following the output quite similar to what other linting tools report (line by line errors with the breaking issue reported) making it quite straight-forward to adjust our code accordingly.

The Closure Linter doesnt just lint code, however. It also includes a script called fixjsstyle which allows us to force (or beautify if you prefer) our code to follow Google's Style Guide.

Now, it is possible to use both the linter and beautifier scripts independently, but as a Sublime Text user, I would love to be able to simply use some keyboard shortcuts to lint or beautify my code using Closure Linter as I write it. Thankfully, someone already thought of this and theres a handy Sublime package available that does just this.

  1. To install: Add this repository to Package Control: https://github.com/fbzhong/sublime-closure-linter and install.

  2. Restart Sublime Text

  3. You should now be able to lint or beautify your code using the following shortcuts:

    • Run/Execute Closure Linter ctrl+shift+j
    • Fix JavaScript Style ctrl+alt+shift+j
    • Show Closure Linter Results in the console

    Note: If you experience issues with paths to the linter tools not being correct, make sure that they have been correctly installed to /usr/bin. They may have been pulled into /local/usr/bin instead and you may need to either create a symbolic link to them or copy the files over to where the package is attempting to access them from.

jsBeautifier

jsBeautifier is another useful tool which you've most likely heard of before if not currently using at the moment. It accepts everything from poorly formatted JavaScript to fully minified code, applying a number of spacing/break best practices for making the code more readable. Its been possible to just use jsBeautifier from the terminal (and the popular jsbeautifier.org website) since it was first released, but similar to Googles Closure Linter, it would be incredibly helpful to have this available from directly within our text editor.

Luckily, there is also a Sublime Text package for jsBeautifier which can be downloaded from here. Installation just takes a minute.

  1. Extract and copy the package to your Sublime packages folder (the relevant path will be the same as the first step in the Closure Linter instructions above)
  2. Restart Sublime Text
  3. You can now beautify your code using ctrl+alt+f

Note: You may also be interested in jsFormat – another JavaScript formatting plugin for Sublime which similarly uses jsBeautifier. It's also available on Package Control and should show up in your install list with no changes.

Code Painter

Whilst the above two beautification tools are helpful for improving readability, what developers really need is a solution thats more flexible.

We might not fully agree with the style guide choices enforced by Google Closure Linter or jsBeautifier. What if we would rather our code followed Rick Waldrons Idiomatic.js style guide? or the Dojo style guide? or something more custom?. It doesnt really make a great deal of sense to create new tools for supporting beautification of each individual type of style guide but thankfully there's a tool we can use to solve this problem.

It's a node.js based solution called Code Painter and it allows us to specify a sample JavaScript file following whatever style guide we wish as input, along with the code we would like beautified. Code Painter will infer the style rules to follow based on the sample and then transform our input as necessary.

From Jakub Wieczorek, the developer:

Code Painter is useful when you're working on a code change to a project and you want to make sure your new code fits its style. This could also be integrated with an editor so that it reformats your code as you type based on the style you've been using so far in a particular file. The solution is essentially a pipeline that consists of a tokenizer based on Esprima (with a few modifications to preserve comments and whitespaces), then a bunch of different style processors in the middle (one for each style property) and ends with a serializer that turns the token stream back into source code (this is a completely lossless process).

At the moment Code Painter only supports transformation of about 7 aspects of code style, but this may be enough for your needs. It shouldn't take long to see if it's able to handle the specific style rules you would like your project to enforce, so do check it out!

Code Painter can be grabbed from here and used as follows (assuming you already have Node):

./bin/codepaint -i myApp.js -s styleSample.js -o myAppStyled.js

Conclusions & Further Tips

  • Maintaining a consistent formatting style for your code has a number of advantages, whether you opt to use someone else's style guide or your own. Many developers have found it useful to create a personal style guide with what they consider the 'best bits' of numerous others.
  • Make effective use of whitespace to aid the readability of what you write.
  • Use short, meaningful names for variables, functions and modules. This can help reduce the need for detailed inline comments if it means a developer can instantly grasp the purpose of a piece of code.
  • Avoid code that is repetitive or can be rewritten to be shorter or more readable. This doesn't necessarily mean forcing everything to use the ternary operator or an or condition as we saw in our example. It is perfectly fine to keep code in an extended form, as long as it is easy to follow
  • Where possible, maintain the principles 'You are not going to need it' (YAGNI) and Keep it short and simple (KISS) when coding. These again can help lower verbosity and improve how easy it can be to read what you're written.

That's it. I hope this guide is at least a little useful to someone out there : )

I'm always eager to hear about other takes on this topic or other published style guides. If you would like to contribute to the discussion, feel free to leave a comment or hit me up on Twitter. Cheers!

Many thanks to Sindre Sorhus for his technical review of this post and many useful suggestions that helped improve it.

68 Comments

  1. Great article as always Addy, however one thing I disagree on in particular moving the counter variable “i” out of the loop. Out of interest, if you were writing your own project from scratch, would you abide by this? I don’t particularly see any real advantages to doing this? It just seems to clutter the initial var declaration and make it a little less clear that i is used purely for looping.

    • That’s a very valid point, Jack. I believe James Padolsey also made a similar one on Twitter and I have to say that in my own personal projects, I usually *don’t* abide by the idea of moving “i” out of the loop. I would say it’s a stylistic choice at best, but doesn’t exactly kill style if you decide not to move it up.

      I guess where it does make sense is if you know you’re highly unlikely to be setting your pointer to anything other than (say, 0) initially and repeatedly setting it inline in each loop feels cumbersome or like it doesn’t really add value.

      Other than that, I’m glad you enjoyed the rest of the article!

      • I found myself writing pieces of JS that routinely loop within same scope, reusing `ii and `l’. Moving for loops up and down was an annoyance since that meant moving “var” part. In that case moving “i, l” up makes sense a lot.

        so the format I found most used by me is:

        var i, l

        for ( i = starting_value_1, l = len_value_1; i < l; i++ ) { … }

        for ( i = starting_value_2, l = len_value_2; i < l; i++ ) { … }

        thus, each of for loops can be moved over each other without me caring about declaration.

      • I agree a bit with both. I always declare i outside of the loop, however I also include it in the for statement:

        var i = 0,
        l = 10;

        for( i; i < l; i++ ) {

        }

        Even though using white space with a semicolon is valid syntactically, I find it confuses a number of developers. Any convention that causes a developer to spend even 1 additional second analyzing something as trivial as a for loop is a bad one IMHO.

        Great post!

    • I wrote Idiomatic.js and I abide by that practice in all new projects. JavaScript hoists all initializations to the top – so why not code that way so there’s no confusion. Not doing so is as dumb as initializing a variable in the body of an IfStatement.

      • JavaScript does not hoist all your initializations to the top. All variables belonging to an execution context are created when the execution context is entered, and initialised to undefined. Variables are not initialised to your values until the variable statement is executed (wherever that might be), not when the variable is created.

        Local variable creation is more of a parsing activity than an execution activity, you don’t need to know about it at all, so it doesn’t really make sense to move any of your declarations just for that reason. (For other reasons, maybe.)

        Using the var keyword just declares the scope of the variable, nothing else. Nothing is ‘moved’, the variable is bound to the function’s activation object by the parser (just like the function’s parameter arguments). As long as you understand there is only program scope and function scope, there’s no confusion at all.

        Some people prefer to declare all the variables at the top of their scope as a form of data dictionary, which is fine, but for temporary variables, one might wish to declare them closer to where they are first initialised (e.g. within loop initialisers) this follows the Don’t Repeat Yourself principle more closely, if the variable cannot be initialised early (separating the declaration and initialisation unnecessarily is avoidably repeating yourself).

  2. Excellent guide Addy. With backbase, we write something like var i, iMax; for (i=0, iMax=checkboxes.length; i < iMax; i++). I see this resembles your POV.

    I am happy,

    EP

    • I also have to say that for ( ; i < l; i++ ) { is not more readable and less cluttered but more of a stumbling block as breaks the previous condition during loop condition end condition syntax.

      I started presetting all the counter and loop variables in one statement:

      var i = j = current = 0; or something like that.

      Also, I try to avoid loops that need two variables and when it doesn't matter what order you go through them I normally tend to do a while:

      var i = checkboxes.length;
      while ( i– ) {

      }
      This is very short indeed and works well.

      • I’m sure you and everyone here know that, but to make it clear:
        (function(){ var i = j = current = ‘value’ })();
        defines “j” and “current” variables in the _global_ scope, what is commonly considered harmful.

  3. I don’t like your “var” block, because it is very error-prone. Imagine this:
    var ret,
    out;
    hello = “Hello”,
    num = 1,
    i = 0,
    l = bar.length;
    Boom! You created 4 global variables instead of 6 local ones. Without errors. Just becausa of a distraction or because you are so used to type ; at the end-of-line that you do it without thinking.
    There are other things I prefer to do differently, but I agree that a style should be decided, adopted and shares within an organization.

    • My take is that the var block as presented works where a developer is being vigilant. If we were to run the version with the correct commas through say, jsHint, as long as the bar variable has been defined previously (which it is as a function argument), everything clears okay. The version with a semicolon incorrectly/accidentally placed will however throw errors stating that hello, num etc. are not defined.

      That said, I think you’re right – as long as whatever style is adopted is maintained consistently, a developer or their team should be okay.

    • Semicolon-less, comma-first style from NPM is perhaps best for this case as it insures there is nothing dangling at the end ever.

      var a
      , b
      , c
      , d

    • Yes, but there aren’t any best practices. Use whatever you like and stick to it. If working on others code, follow their style. If you’re a team, create a quick little style guide. And dont forget; consistency is king.

  4. Interesting, Must agree with Jack, it is not always practical to have variable declaration outside of a loop, however it must be remembered that a code style expectation is there for a reason and the practical separation of when something is acceptable and when not is often, disconnected from reality. Rather run with the expectation of what needs to be done according to the style guide. This is a very fundamental philosophy that often cognitively creates an expectation to do thing according to the “guide”, not leaving any room for misinterpretation of an code style expectation.

  5. Great article, thank you.

    I believe my style resembles the most jQuery’s without the extra whitespace. I believe extra whitespace does make the code more readable, however I’m really not fond of the exceptions they have to this “add-extra-whitespace” rule.

    In my opinion, exceptions = confusion = decreased code readability.

  6. There are other packages you can get for Sublime Text 2 that can actively lint files you’re working on. Make sure you check out this SublimeLinter package: https://github.com/Kronuz/SublimeLinter

    p.s. Any chance you could enhance your comments form with HTML5 form elements? It’s a pain typing email addresses and URLs on iPad/tablets with text fields. :)

    • Thanks for the additional package suggestion!.

      re: enhancement with form elements, I’ll see what I can do :)

  7. Give me “View As” and “Save As” and “quickly build your own style” in editors.
    This way you can always use your own preferred style, without messing it up for others.

  8. Good article. It’s a sign of the language’s and the community’s maturity that this has become a topic. Good to see.

    But …

    ….return ret || func(whatever); // horrible code!

    First, only a JS ace can read it. Your maintainer could very well be a Snobol coder dragged in because no one else was available. She doesn’t know JS falsy values. You should always write so ANYONE can read your code; never so that only fellow afficionados can read your code.

    Second, logic should be complete before you return a value. You want to be able to stop execution before the return statement, inspect values, (see what dumb mistake you made). Almost no debuggers can stop in the middle of an expression. So let’s try again:

    ….if ( ret === undefined ) { ret = func( whatever ); }

    …. // put a breakpoint (or cons.out or …) here, if needed

    ….return ret;

  9. Pingback: JavaScript Style Guides And Beautifiers | viczam

  10. Pingback: JavaScript Style Guides And Beautifiers | viczam

  11. I’m moving to the IdiomaticJS code style, but I’m a little disapointed there are no code hints for OOP coding style.

    So is this correct ? My only concern is about the public variables, with a this.myPublicVar = …

    Where should I put them ? In the the init method or in the contructor ? How can I declare them properly ? Writing “this.myPublicVar = null”; in the constructor wouldn’t be verboose ?

    (function () {

    ‘use strict’;

    //Constructor
    function MyClass(prop1, prop2) {
    this.initialize(prop1, prop2);
    }

    //Inheritance
    MyClass.prototype = new MyParentClass();

    //Private variables declarations
    var myPrivateVar1,
    myPrivateVar2,
    myPrivateVar3;

    //public function
    MyClass.prototype.initialize = function (prop1, prop2) {
    //public variables
    this.myPublicVar1 = prop1;
    this.myPublicVar2 = prop2;
    };

    //private function
    var myPrivateFunction = function(prop1){
    return prop1;
    };
    window.nameSpace.MyClass = MyClass;
    })();

    What’s your opinion ?

  12. Awesome article, as usual!

    I’ve got Node+Express on backend and Backbone+JQuery on frontend for my last SPA project.
    After first year of developing the code started to look ugly as more features were added and there was no time for refactoring the old code. A quick solution was to switch to CoffeeScript that increased a lot the code readability. It was a bless for the stacked callback calls from the entire Node code caused by Mongooose.

    Another win was to switch to a pub/sub events system on frontend that I’ve read about it in your Javascript Patterns book. Decoupling my app in standalone modules increased the code readability a lot.

  13. Pingback: Linkdump for May 6th | found drama

  14. Pingback: Link: JavaScript Style Guides And Beautifiers « しあわせ Code

  15. Pingback: Move that parenthesis! – James Padolsey

  16. Two minor points…. First, in your original, you perform an identity comparison of out against an empty string. I assume that was not your intention as that doesn’t translate into !out (in your second reference to it, you use equality).

    Second, I found the use of i for the loop counter and l for the array length to be visually tough to read as the two characters are so similar. I initially read your modified loop’s conditional to be i < i, and was very much looking forward to the explanation of that!

    Thanks for the good synopsis of JavaScript guides and beautifiers!

  17. Coding style seem to be a very emotional thing for some people – it shouldn’t. There are many different styles out there to format your code – let it be JavaScript, C# or whatever – and they did evolve over time. Some of the ideas on how to provide readability have simply been proven false and have been corrected in some areas – but reinvented in others. E.g. using upper casing for constants has been removed from the list of “recommended” coding style when introducing StyleCop for C# (upper case constant names have been used in C for decades – but in the context of multi-language development they do not make sense any more: since some languages are not case sensitive and using “casing” as a distinction between different variables is not recommended in such a modern environment).
    Some years ago there was a recommendation for “developing a coding style guide for your company” – I don’t think that this a good idea … and I think that using some parts of this guide and other parts of that guide is a really bad idea, too.
    If you use a “standard” (or “guide”, because there currently is no “standard”), then use it completely – do not customize. Love it or leave it – but do not change it until you are the inventor of that guide. When you start in a new project it would be very easy to start coding, when the coding guide is “JQuery Core Style Guidelines”, but it will be very hard, if you have a document with 20 sections referencing 10 different guides.

    If you are the inventor of a guide – PLEASE DO HAVE A LOOK ON STYLES OF OTHER LANGUAGES. To only have “JavaScript” in mind when thinking about a good formatting for “var”, “if” or “for” keywords is really very ignorant. An increasing amount of people dealing with JavaScript do also write code in C#, Java, PHP, VB, Pearl, Ruby or other languages – and most of them would like to have a consistent coding style. If “your” guide does not match the needs of those people, it will die over time.

  18. Pingback: Top 5 from the 17th+18th week: Typography, Data, Javascript — 48techblog

  19. It’s all fun and games until someone tells me to use a space after each bracket, brace, comma, equal, not equal, plus, minus etc.

  20. Addy ,

    This is a nice article .. Really loved it.

    But my concern is about changing the following line

    if (!(ret == undefined)) {
    return ret;
    } else{
    return fum(‘g2g’);
    }

    to

    return ret || fum(‘g2g’);

    What if we’re expecting a return value as ’0′. Here in this case when the ret value is ’0′ the statement

    return ret || fum(‘g2g’);

    always executes the fum(‘g2g’) only. Which developers won’t think about always.

  21. It is more readable (to me) for the open { and the closing brace }
    to be at the same level of indent.

    I wish the JavaScript community would adopt it as a standard.

  22. Pingback: Weekly HTML5 Apps Developer Resources, May 8th 2012 ✩ Mozilla Hacks – the Web developer blog

  23. Pingback: Must Read Articles of The Week #13 | Wordpress Junkie  

  24. Pingback: Javascript Part.1 : Bonne pratiques | Maxlab | Le Blog

  25. I dunno, you might prefer to declare your variables up-front, but to initialise them too? Now you’re on shaky ground, because moving the declaration is stylistic whereas moving the initialisation is not.

    I wouldn’t forsake the initialiser section of the for() syntax personally, if a loop requires initialisation, I’ll jolly well do it in the for() statement, thank you very much. That loop can then easily be moved to a different place in the code, another function, module, file, anywhere, safely. (Even safer if the var keyword was inline and moved with it too).

    There’s an art to writing code that’s easy to maintain and refactor. You need to have a style that reflects an in-depth knowledge of programming, not an in-depth knowledge of the specific language.

    I would argue any experienced programmer could understand your starting point (before improvements), but only experienced JavaScript programmers can understand your finished article.

  26. Pingback: Tweet-Parade (no.19 May 2012) | gonzoblog.nl

  27. in your example 4 conditional eval… i know from personal exerience that there’s a difference in evaluating for nulls(or ‘falsy’ vals) vs. empty strings. If your variable fails to pass in at all then obviously eval for empty string will error.. but if you pass an empty string and eval as !x, it’s going to sneak thru with a fale-positive.

    as for my style, i guess i leave it to my IDE to a certain extent (MSVS) which handles all the whitespaces and ‘pretty formatting’.. i just try to keep it clean/readable. i’m also a proponent of on the fly documentation mixed thru the code (for my own benefit!).

    i just wish js was more intuitive from the developers side (collapsable functions, tree or other overview of where the function is located on the page/in the project..similar to .net code). feels like i spend more time looking for functions than writing them sometimes, or checking if objects were already declared, function names already used, etc..lol.

  28. I use CoffeeScript to write my js files. In doing so, I have some constraints linked to the CoffeeScript syntax, and I loved it. I have to write in the CoffeeScript way, or it doesn’t work. Only one way, thus no headache in order to find the better way!

  29. Great post, just what I was looking for…any chance you are going to be getting any early copies of your book on backbone.js? I need it!!!

  30. Pingback: RPGIV: Cycle or not? In-line code or subroutines? Is anybody still asking this? « IBM Midrange Programming

  31. Pingback: Code Linting | Luke Askew

  32. My designer is good with all these style guides and I have passed over this information to him, he raised a question and here it is: Does all these JS style guides support the text audio option too?

  33. Pingback: thedevgroup: Great article on modern JS best practices and tools to help you. – devdump

  34. I’ve used double quotes for add long as I can remember, but recently I decided to give single quotes a go. I’m presently surprised, not only is it more efficient, sine you don’t have to hold down shift, but it makes the code look lighter. This is probably due to the fact that one double quote is about the size of two single quotes. consistency is most important, and I’ll try too use single quotes for new projects, from now on.

  35. Pingback: Tweet-Parade (no.19 May 2012) - The Best Articles of Last Week | gonzoblog

  36. Pingback: A meta style guide for JavaScript | InfoLogs

  37. Pingback: There is no “I” in coding | SoshiTech

Leave a Reply

Required fields are marked *.