Principles of Writing Consistent, Idiomatic JavaScript

This is taken from https://github.com/rwaldron/idiomatic.js

All code in any code-base should look like a single person typed it, no matter how many people contributed.

The following list outlines the practices that JavaScript developers are expected to follow

"Arguments over style are pointless. There should be a style guide, and you should follow it" Rebecca Murphey

"Part of being a good steward to a successful project is realizing that writing code for yourself is a Bad Idea. If thousands of people are using your code, then write your code for maximum clarity, not your personal preference of how to get clever within the spec." Idan Gazit

Table of Contents

• Whitespace
• Beautiful Syntax
• Type Checking (Courtesy jQuery Core Style Guidelines)
• Conditional Evaluation
• Practical Style
• Naming
• Misc
• Native & Host Objects
• Comments
• One Language Code

---

Preface

The following sections outline a reasonable style guide for modern JavaScript development and are to be adopted for consistency.

Idiomatic Style Manifesto

1. Whitespace

• Never mix spaces and tabs.
• Always use 4 spaces for indentation. You can set your IDE to this.
• If your editor supports it, always work with the "show invisibles" setting turned on. The benefits of this practice are:
  • Enforced consistency
  • Eliminating end of line whitespace
  • Eliminating blank line whitespace
  • Commits and diffs that are easier to read

2. Beautiful Syntax

   A. Parens, Braces, Linebreaks

   // if/else/for/while/try always have spaces, braces and span multiple lines
   // this encourages readability
   
   // 2.A.1.1
   // Examples of really cramped syntax
   
   if(condition) doSomething();
   
   while(condition) iterating++;
   
   for(var i=0;i<100;i++) someIterativeFn();
   
   
   // 2.A.1.1
   // Use whitespace to promote readability
   
   if ( condition ) {
       // statements
   }
   
   while ( condition ) {
       // statements
   }
   
   for ( var i = 0; i < 100; i++ ) {
       // statements
   }
   
   // Even better:
   
   var i,
       length = 100;
   
   for ( i = 0; i < length; i++ ) {
       // statements
   }
   
   var prop;
   
   for ( prop in object ) {
       // statements
   }
   
   
   if ( true ) {
       // statements
   } else {
       // statements
   }

   B. Assignments, Declarations, Functions ( Named, Expression, Constructor )

   // 2.B.1.1
   // Variables
   var foo = "bar",
       num = 1,
       undef;
   
   // Literal notations:
   var array = [],
       object = {};
   
   
   // 2.B.1.2
   // Using only one `var` per scope (function) promotes readability
   // and keeps your declaration list free of clutter (also saves a few keystrokes)
   
   // Bad
   var foo = "";
   var bar = "";
   var qux;
   
   // Good
   var foo = "",
       bar = "",
       quux;
   
   // or..
   var // Comment on these
       foo = "",
       bar = "",
       quux;
   
   // 2.B.1.3
   // var statements should always be in the beginning of their respective scope (function).
   // Same goes for const and let from ECMAScript 6.
   
   // Bad
   function foo() {
   
       // some statements here
   
       var bar = "",
           qux;
   }
   
   // Good
   function foo() {
       var bar = "",
           qux;
   
       // all statements after the variables declarations.
   }

   // 2.B.2.1
   // Named Function Declaration
   function foo( arg1, argN ) {
   
   }
   
   // Usage
   foo( arg1, argN );
   
   
   // 2.B.2.2
   // Named Function Declaration
   function square( number ) {
       return number * number;
   }
   
   // Usage
   square( 10 );
   
   // Really contrived continuation passing style
   function square( number, callback ) {
       callback( number * number );
   }
   
   square( 10, function( square ) {
       // callback statements
   });
   
   
   // 2.B.2.3
   // Function Expression
   var square = function( number ) {
       // Return something valuable and relevant
       return number * number;
   };
   
   // Function Expression with Identifier
   // This preferred form has the added value of being
   // able to call itself and have an identity in stack traces:
   var factorial = function factorial( number ) {
       if ( number < 2 ) {
           return 1;
       }
   
       return number * factorial( number - 1 );
   };
   
   
   // 2.B.2.4
   // Constructor Declaration
   function FooBar( options ) {
   
       this.options = options;
   }
   
   // Usage
   var fooBar = new FooBar({ a: "alpha" });
   
   fooBar.options;
   // { a: "alpha" }

   C. Exceptions, Slight Deviations

   // 2.C.1.1
   // Functions with callbacks
   foo(function() {
       // Note there is no extra space between the first paren
       // of the executing function call and the word "function"
   });
   
   // Function accepting an array, no space
   foo([ "alpha", "beta" ]);
   
   // 2.C.1.2
   // Function accepting an object, no space
   foo({
       a: "alpha",
       b: "beta"
   });
   
   // Single argument string literal, no space
   foo("bar");
   
   // Inner grouping parens, no space
   if ( !("foo" in obj) ) {
   
   }

   D. Quotes

   Double quotes should be used.

   E. End of Lines and Empty Lines

   Whitespace should be stripped from line endings and empty lines. You can set your IDE to do this..

3. Type Checking (Courtesy jQuery Core Style Guidelines)

   A. Actual Types

   String:

    typeof variable === "string"
   

   Number:

    typeof variable === "number"
   

   Boolean:

    typeof variable === "boolean"
   

   Object:

    typeof variable === "object"
   

   Array:

    Array.isArray( arrayLikeObject )
    (wherever possible)
   

   Node:

    elem.nodeType === 1
   

   null:

    variable === null
   

   null or undefined:

    variable === null || typeof variable === "undefined"
   

   undefined:

   Global Variables:

    typeof variable === "undefined"
   

   Local Variables:

    typeof variable === "undefined"
   

   Properties:

    typeof object.prop === "undefined"
    object.hasOwnProperty( prop )
    "prop" in object
   

   B. Coerced Types

   Consider the implications of the following...

   Given this HTML:

   <input type="text" id="foo-input" value="1">

   // 3.B.1.1
   
   // `foo` has been declared with the value `0` and its type is `number`
   var foo = 0;
   
   // typeof foo;
   // "number"
   ...
   
   // Somewhere later in your code, you need to update `foo`
   // with a new value derived from an input element
   
   foo = document.getElementById("foo-input").value;
   
   // If you were to test `typeof foo` now, the result would be `string`
   // This means that if you had logic that tested `foo` like:
   
   if ( foo === 1 ) {
   
       importantTask();
   
   }
   
   // `importantTask()` would never be evaluated, even though `foo` has a value of "1"
   
   
   // 3.B.1.2
   
   // You can preempt issues by using smart coercion with unary + or - operators:
   
   foo = +document.getElementById("foo-input").value;
   //    ^ unary + operator will convert its right side operand to a number
   
   // typeof foo;
   // "number"
   
   if ( foo === 1 ) {
   
       importantTask();
   
   }
   
   // `importantTask()` will be called

   Here are some common cases along with coercions:

   // 3.B.2.1
   
   var number = 1,
       string = "1",
       bool = false;
   
   number;
   // 1
   
   number + "";
   // "1"
   
   string;
   // "1"
   
   +string;
   // 1
   
   +string++;
   // 1
   
   string;
   // 2
   
   bool;
   // false
   
   +bool;
   // 0
   
   bool + "";
   // "false"

   // 3.B.2.2
   
   var number = 1,
       string = "1",
       bool = true;
   
   string === number;
   // false
   
   string === number + "";
   // true
   
   +string === number;
   // true
   
   bool === number;
   // false
   
   +bool === number;
   // true
   
   bool === string;
   // false
   
   bool === !!string;
   // true

   // 3.B.2.3
   
   var array = [ "a", "b", "c" ];
   
   !!~array.indexOf("a");
   // true
   
   !!~array.indexOf("b");
   // true
   
   !!~array.indexOf("c");
   // true
   
   !!~array.indexOf("d");
   // false
   
   // Note that the above should be considered "unnecessarily clever"
   // Prefer the obvious approach of comparing the returned value of
   // indexOf, like:
   
   if ( array.indexOf( "a" ) >= 0 ) {
     // ...
   }

   // 3.B.2.4
   
   
   var num = 2.5;
   
   parseInt( num, 10 );
   
   // is the same as...
   
   ~~num;
   
   num >> 0;
   
   num >>> 0;
   
   // All result in 2
   
   
   // Keep in mind however, that negative numbers will be treated differently...
   
   var neg = -2.5;
   
   parseInt( neg, 10 );
   
   // is the same as...
   
   ~~neg;
   
   neg >> 0;
   
   // All result in -2
   // However...
   
   neg >>> 0;
   
   // Will result in 4294967294
   
   
   

4. Conditional Evaluation

   // 4.1.1
   // When only evaluating that an array has length,
   // instead of this:
   if ( array.length > 0 ) ...
   
   // ...evaluate truthiness, like this:
   if ( array.length ) ...
   
   
   // 4.1.2
   // When only evaluating that an array is empty,
   // instead of this:
   if ( array.length === 0 ) ...
   
   // ...evaluate truthiness, like this:
   if ( !array.length ) ...
   
   
   // 4.1.3
   // When only evaluating that a string is not empty,
   // instead of this:
   if ( string !== "" ) ...
   
   // ...evaluate truthiness, like this:
   if ( string ) ...
   
   
   // 4.1.4
   // When only evaluating that a string _is_ empty,
   // instead of this:
   if ( string === "" ) ...
   
   // ...evaluate falsy-ness, like this:
   if ( !string ) ...
   
   
   // 4.1.5
   // When only evaluating that a reference is true,
   // instead of this:
   if ( foo === true ) ...
   
   // ...evaluate like you mean it, take advantage of built in capabilities:
   if ( foo ) ...
   
   
   // 4.1.6
   // When evaluating that a reference is false,
   // instead of this:
   if ( foo === false ) ...
   
   // ...use negation to coerce a true evaluation
   if ( !foo ) ...
   
   // ...Be careful, this will also match: 0, "", null, undefined, NaN
   // If you _MUST_ test for a boolean false, then use
   if ( foo === false ) ...
   
   
   // 4.1.7
   // When only evaluating a ref that might be null or undefined, but NOT false, "" or 0,
   // instead of this:
   if ( foo === null || typeof foo === "undefined" ) ...

   ALWAYS evaluate for the best, most accurate result - the above is a guideline, not a dogma.

   // 4.2.1
   // Type coercion and evaluation notes
   
   // Always use `===` over `==`
   
   // === does not coerce type, which means that:
   
   "1" === 1;
   // false
   
   // 4.2.2
   // Booleans, Truthies & Falsies
   
   // Booleans:
   true, false
   
   // Truthy:
   "foo", 1
   
   // Falsy:
   "", 0, null, undefined, NaN, void 0

5. Practical Style

   // 5.1.1
   // A Practical Module
   
    (function( global ) {
       var Module = (function() {
   
           var data = "secret";
   
           return {
               // This is some boolean property
               bool: true,
               // Some string value
               string: "a string",
               // An array property
               array: [ 1, 2, 3, 4 ],
               // An object property
               object: {
                   lang: "en-Us"
               },
               getData: function() {
                   // get the current value of `data`
                   return data;
               },
               setData: function( value ) {
                   // set the value of `data` and return it
                   return ( data = value );
               }
           };
       })();
   
       // Other things might happen here
   
       // expose our module to the global object
       global.Module = Module;
   
   })( this );

   // 5.2.1
   // A Practical Constructor

(function( global ) {

function Ctor( foo ) {

    this.foo = foo;

    return this;
}

Ctor.prototype.getFoo = function() {
    return this.foo;
};

Ctor.prototype.setFoo = function( val ) {
    return ( this.foo = val );
};


// To call constructor's without `new`, you might do this:
var ctor = function( foo ) {
    return new Ctor( foo );
};


// expose our constructor to the global object
global.ctor = ctor;

})( this );

```

6. Naming

   A. You are not a human code compiler/compressor, so don't try to be one.

   The following code is an example of egregious naming:

   // 6.A.1.1
   // Example of code with poor names
   
   function q(s) {
     return document.querySelectorAll(s);
   }
   var i,a=[],els=q("#foo");
   for(i=0;i<els.length;i++){a.push(els[i]);}

   Without a doubt, you've written code like this - hopefully that ends today.

   Here's the same piece of logic, but with kinder, more thoughtful naming (and a readable structure):

   // 6.A.2.1
   // Example of code with improved names
   
   function query( selector ) {
     return document.querySelectorAll( selector );
   }
   
   var i = 0,
     elements = [],
     matches = query("#foo"),
     length = matches.length;
   
   for ( ; i < length; i++ ) {
     elements.push( matches[ i ] );
   }

   A few additional naming pointers:

   // 6.A.3.1
   // Naming strings
   
   `dog` is a string
   
   
   // 6.A.3.2
   // Naming arrays
   
   `dogs` is an array of `dog` strings
   
   
   // 6.A.3.3
   // Naming functions, objects, instances, etc
   
   camelCase; function and var declarations
   
   
   // 6.A.3.4
   // Naming constructors, prototypes, etc.
   
   PascalCase; constructor function
   
   
   // 6.A.3.5
   // From the Google Closure Library Style Guide
   
   functionNamesLikeThis;
   variableNamesLikeThis;
   ConstructorNamesLikeThis;
   methodNamesLikeThis;
   SYMBOLIC_CONSTANTS_LIKE_THIS;

   B. Faces of this

   Beyond the generally well known use cases of call and apply, always prefer .bind( this ) or a functional equivalent, for creating BoundFunction definitions for later invocation. Only resort to aliasing when no preferable option is available.

   // 6.B.1
   function Device( opts ) {
   
       this.value = null;
   
       // open an async stream,
       // this will be called continuously
       stream.read( opts.path, function( data ) {
   
           // Update this instance's current value
           // with the most recent value from the
           // data stream
           this.value = data;
   
       }.bind(this) );
   
       // Throttle the frequency of events emitted from
       // this Device instance
       setInterval(function() {
   
           // Emit a throttled event
           this.emit("event");
   
       }.bind(this), opts.freq || 100 );
   }
   
   // Just pretend we've inherited EventEmitter ;)

   When unavailable, functional equivalents to .bind exist in many modern JavaScript libraries.

   // 6.B.2
   
   // eg. lodash/underscore, _.bind()
   function Device( opts ) {
   
       this.value = null;
   
           stream.read( opts.path, _.bind(function( data ) {
   
       this.value = data;
   
       }, this) );
   
       setInterval(_.bind(function() {
   
           this.emit("event");
   
       }, this), opts.freq || 100 );
   }
   
   // eg. jQuery.proxy
   function Device( opts ) {
   
       this.value = null;
   
       stream.read( opts.path, jQuery.proxy(function( data ) {
   
           this.value = data;
   
       }, this) );
   
       setInterval( jQuery.proxy(function() {
   
           this.emit("event");
   
       }, this), opts.freq || 100 );
   }
   
   // eg. dojo.hitch
   function Device( opts ) {
   
       this.value = null;
   
       stream.read( opts.path, dojo.hitch( this, function( data ) {
   
           this.value = data;
   
       }) );
   
       setInterval( dojo.hitch( this, function() {
   
           this.emit("event");
   
       }), opts.freq || 100 );
   }

   As a last resort, create an alias to this using self as an Identifier. This is extremely bug prone and should be avoided whenever possible.

   // 6.B.3
   
   function Device( opts ) {
       var self = this;
   
       this.value = null;
   
       stream.read( opts.path, function( data ) {
   
           self.value = data;
   
       });
   
       setInterval(function() {
   
           self.emit("event");
   
       }, opts.freq || 100 );
   }

   C. Use thisArg

   Several prototype methods of ES 5.1 built-ins come with a special thisArg signature, which should be used whenever possible

   // 6.C.1
   
   var obj;
   
   obj = { f: "foo", b: "bar", q: "qux" };
   
   Object.keys( obj ).forEach(function( key ) {
   
       // |this| now refers to `obj`
   
       console.log( this[ key ] );
   
   }, obj ); // <-- the last arg is `thisArg`
   
   // Prints...
   
   // "foo"
   // "bar"
   // "qux"

   thisArg can be used with Array.prototype.every, Array.prototype.forEach, Array.prototype.some, Array.prototype.map, Array.prototype.filter

7. Misc

   This section will serve to illustrate ideas and concepts that should not be considered dogma, but instead exists to encourage questioning practices in an attempt to find better ways to do common JavaScript programming tasks.

   A. Using switch should be avoided, modern method tracing will blacklist functions with switch statements

   There seems to be drastic improvements to the execution of switch statements in latest releases of Firefox and Chrome. http://jsperf.com/switch-vs-object-literal-vs-module

   Notable improvements can be witnesses here as well: rwaldron#13

   // 7.A.1.1
   // An example switch statement
   
   switch( foo ) {
       case "alpha":
           alpha();
           break;
       case "beta":
           beta();
           break;
       default:
           // something to default to
           break;
   }
   
   // 7.A.1.2
   // A alternate approach that supports composability and reusability is to
   // use an object to store "cases" and a function to delegate:
   
   var cases, delegator;
   
   // Example returns for illustration only.
   cases = {
       alpha: function() {
           // statements
           // a return
           return [ "Alpha", arguments.length ];
       },
       beta: function() {
           // statements
           // a return
           return [ "Beta", arguments.length ];
       },
       _default: function() {
           // statements
           // a return
           return [ "Default", arguments.length ];
       }
   };
   
   delegator = function() {
       var args, key, delegate;
   
       // Transform arguments list into an array
       args = [].slice.call( arguments );
   
       // shift the case key from the arguments
       key = args.shift();
   
       // Assign the default case handler
       delegate = cases._default;
   
       // Derive the method to delegate operation to
       if ( cases.hasOwnProperty( key ) ) {
           delegate = cases[ key ];
       }
   
       // The scope arg could be set to something specific,
       // in this case, |null| will suffice
       return delegate.apply( null, args );
   };
   
   // 7.A.1.3
   // Put the API in 7.A.1.2 to work:
   
   delegator( "alpha", 1, 2, 3, 4, 5 );
   // [ "Alpha", 5 ]
   
   // Of course, the `case` key argument could easily be based
   // on some other arbitrary condition.
   
   var caseKey, someUserInput;
   
   // Possibly some kind of form input?
   someUserInput = 9;
   
   if ( someUserInput > 10 ) {
       caseKey = "alpha";
   } else {
       caseKey = "beta";
   }
   
   // or...
   
   caseKey = someUserInput > 10 ? "alpha" : "beta";
   
   // And then...
   
   delegator( caseKey, someUserInput );
   // [ "Beta", 1 ]
   
   // And of course...
   
   delegator();
   // [ "Default", 0 ]
   

   B. Early returns promote code readability with negligible performance difference

   // 7.B.1.1
   // Bad:
   function returnLate( foo ) {
       var ret;
   
       if ( foo ) {
           ret = "foo";
       } else {
           ret = "quux";
       }
       return ret;
   }
   
   // Good:
   
   function returnEarly( foo ) {
   
       if ( foo ) {
           return "foo";
       }
           return "quux";
       }

8. Native & Host Objects

   The basic principle here is:

   Don't do stupid shit and everything will be ok.

   To reinforce this concept, please watch the following presentation:

   "Everything is Permitted: Extending Built-ins" by Andrew Dupont (JSConf2011, Portland, Oregon)

   <iframe src="http://blip.tv/play/g_Mngr6LegI.html" width="480" height="346" frameborder="0" allowfullscreen></iframe>

   http://blip.tv/jsconf/jsconf2011-andrew-dupont-everything-is-permitted-extending-built-ins-5211542

9. Comments

   Single line above the code that is subject

   Multiline is good

   End of line comments are prohibited!

   JSDoc style is required

10. One Language Code

    Programs should be written in one language, whatever that language may be, as dictated by the maintainer or maintainers.

---

Principles of Writing Consistent, Idiomatic JavaScript by Rick Waldron and Contributors is licensed under a Creative Commons Attribution 3.0 Unported License.
Based on a work at github.com/rwldrn/idiomatic.js.