开源软件名称：

开源软件地址：

开源编程语言：

开源软件介绍：

Principles of Writing Consistent, Idiomatic JavaScript

This is a living document and new ideas for improving the code around us are always welcome. Contribute: fork, clone, branch, commit, push, pull request.

• Rick Waldron @rwaldron, github
• Mathias Bynens @mathias, github
• Schalk Neethling @ossreleasefeed, github
• Kit Cambridge @kitcambridge, github
• Raynos github
• Matias Arriola @MatiasArriola, github
• John Fischer @jfroffice, github
• Idan Gazit @idangazit, github
• Leo Balter @leobalter, github
• Breno Oliveira @garu_rj, github
• Leo Beto Souza @leobetosouza, github
• Ryuichi Okumura @okuryu, github
• Pascal Precht @PascalPrecht, github
• EngForDev engfordev - Hwan Min Hong / MinTaek Kwon @leoinsight / Tw Shim @marocchino, github / Nassol Kim @nassol99, github / Juntai Park @rkJun, github / Minkyu Shim / Gangmin Won / Justin Yoo @justinchronicle / Daeyup Lee
• Marco Trulla @marcotrulla, github
• Alex Navasardyan @alexnavasardyan, github
• Mihai Paun @mihaipaun, github
• Evgeny Mandrikov @_godin_, github
• Sofish Lin @sofish, github
• Дејан Димић @dejan_dimic, github
• Miloš Gavrilović @gavrisimo, github
• Firede @firede github
• monkadd github
• Stephan Lindauer @stephanlindauer, github
• Thomas P @dragon5689 github
• Yotam Ofek @yotamofek github
• Aleksandr Filatov @greybax, github
• Duc Nguyen @ducntq, github
• James Young @jamsyoung, github
• Hao-Wei Jeng @l0ckys, github
• Richard Gibson @gibson042, github
• Fesuy github
• Stephane Moreau github
• Boris Nekezov github
• Akshat Joshi @akshat_joshi, github

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 I use in all code that I am the original author of; contributions to projects that I have created should follow these guidelines.

I do not intend to impose my style preferences on other people's code or projects; if an existing common style exists, it should be respected.

"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

Translations

• Bulgarian
• German
• French
• Spanish
• Portuguese - Brazil
• Korean
• 日本語
• Italian
• Russian
• Romanian
• 简体中文
• Serbian - cyrilic alphabet
• Serbian - latin alphabet
• 繁體中文
• Indonesian
• Greek
• Hindi

Important, Non-Idiomatic Stuff:

Code Quality Tools, Resources & References

• SonarQube
• Plato
• jsPerf
• jsFiddle
• Codepen
• jsbin
• JavaScript Lint (JSL)
• jshint
• jslint
• eslint
• jscs
• jscodesniffer
• Editorconfig
• Hound

Get Smart

Annotated ECMAScript 5.1

EcmaScript Language Specification, 5.1 Edition

The following should be considered 1) incomplete, and 2) REQUIRED READING. I don't always agree with the style written by the authors below, but one thing is certain: They are consistent. Furthermore, these are authorities on the language.

• Baseline For Front End Developers: 2015
• Eloquent JavaScript
• JavaScript, JavaScript
• Adventures in JavaScript Development
• Perfection Kills
• Douglas Crockford's Wrrrld Wide Web
• JS Assessment

Build & Deployment Process

Projects should always attempt to include some generic means by which source can be linted, tested and compressed in preparation for production use. For this task, grunt by Ben Alman is second to none and has officially replaced the "kits/" directory of this repo.

Test Facility

Projects must include some form of unit, reference, implementation or functional testing. Use case demos DO NOT QUALIFY as "tests". The following is a list of test frameworks, none of which are endorsed more than the other.

• QUnit
• Jasmine
• Vows
• Mocha
• Hiro
• JsTestDriver
• Buster.js
• Sinon.js
• Tape
• Jest

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 not meant to be prescriptive. The most important take-away is the law of code style consistency. Whatever you choose as the style for your project should be considered law. Link to this document as a statement of your project's commitment to code style consistency, readability and maintainability.

Idiomatic Style Manifesto

1. Whitespace

• Never mix spaces and tabs.
• When beginning a project, before you write any code, choose between soft indents (spaces) or real tabs, consider this law.
  • For readability, I always recommend setting your editor's indent size to two characters — this means two spaces or two spaces representing a real tab.
• 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
• Use Editorconfig when possible. It supports most IDEs and handles most whitespace settings.

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
   }
   
   // Or...
   
   var i = 0,
     length = 100;
   
   for ( ; 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) or one `var` for each variable,
   // promotes readability and keeps your declaration list free of clutter.
   // Using one `var` per variable you can take more control of your versions
   // and makes it easier to reorder the lines.
   // One `var` per scope makes it easier to detect undeclared variables
   // that may become implied globals.
   // Choose better for your project and never mix them.
   
   // Bad
   var foo = "",
     bar = "";
   var qux;
   
   // Good
   var foo = "";
   var bar = "";
   var qux;
   
   // or..
   var foo = "",
     bar = "",
     qux;
   
   // 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).
   
   
   // Bad
   function foo() {
   
     // some statements here
   
     var bar = "",
       qux;
   }
   
   // Good
   function foo() {
     var bar = "",
       qux;
   
     // all statements after the variables declarations.
   }
   
   // 2.B.1.4
   // const and let, from ECMAScript 6, should likewise be at the top of their scope (block).
   
   // Bad
   function foo() {
     let foo,
       bar;
     if ( condition ) {
       bar = "";
       // statements
     }
   }
   // Good
   function foo() {
     let foo;
     if ( condition ) {
       let bar = "";
       // statements
     }
   }

   // 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");
   
   // Expression parens, no space
   if ( !("foo" in obj) ) {
     obj = (obj.bar || defaults).baz;
   }

   D. Consistency Always Wins

   In sections 2.A-2.C, the whitespace rules are set forth as a recommendation with a simpler, higher purpose: consistency. It's important to note that formatting preferences, such as "inner whitespace" should be considered optional, but only one style should exist across the entire source of your project.

   // 2.D.1.1
   
   if (condition) {
     // statements
   }
   
   while (condition) {
     // statements
   }
   
   for (var i = 0; i < 100; i++) {
     // statements
   }
   
   if (true) {
     // statements
   } else {
     // statements
   }

   E. Quotes

   Whether you prefer single or double shouldn't matter, there is no difference in how JavaScript parses them. What ABSOLUTELY MUST be enforced is consistency. Never mix quotes in the same project. Pick one style and stick with it.

   F. End of Lines and Empty Lines

   Whitespace can ruin diffs and make changesets impossible to read. Consider incorporating a pre-commit hook that removes end-of-line whitespace and blanks spaces on empty lines automatically.

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
   

   undefined:

   Global Variables:

    typeof variable === "undefined"
   

   Local Variables:

    variable === undefined
   

   Properties:

    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