[Learn Note] Java Script Guide Line

 

Table of Contents

• 1 Reference
• 2 Highlights
  • 2.1 Formating
    • 2.1.1 Curly Braces
    • 2.1.2 Array and Object Initializers
    • 2.1.3 Function Arguments
    • 2.1.4 Passing Anonymous Functions
    • 2.1.5 More Indentation
    • 2.1.6 Binary and Ternary Operators
  • 2.2 Strings
  • 2.3 JavaScript Types
    • 2.3.1 Type Casts
  • 2.4 Comments
    • 2.4.1 JSDoc Indentation
    • 2.4.2 Top/File-Level Comments

1 Reference

http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml

2 Highlights

 

2.1 Formating

 

2.1.1 Curly Braces

Because of implicit semicolon insertion, always start your curly braces on the same line as whatever they're opening. For example:

if (something) {

  // ...

} else {

  // ...

}

2.1.2 Array and Object Initializers

Single-line array and object initializers are allowed when they fit on a line:

var arr = [1, 2, 3];  // No space after [ or before ].

var obj = {a: 1, b: 2, c: 3};  // No space after { or before }.

Multiline array initializers and object initializers are indented 2 spaces, just like blocks.

// Object initializer.

var inset = {

  top: 10,

  right: 20,

  bottom: 15,

  left: 12

};



// Array initializer.

this.rows_ = [

  '"Slartibartfast" <fjordmaster@magrathea.com>',

  '"Zaphod Beeblebrox" <theprez@universe.gov>',

  '"Ford Prefect" <ford@theguide.com>',

  '"Arthur Dent" <has.no.tea@gmail.com>',

  '"Marvin the Paranoid Android" <marv@googlemail.com>',

  'the.mice@magrathea.com'

];



// Used in a method call.

goog.dom.createDom(goog.dom.TagName.DIV, {

  id: 'foo',

  className: 'some-css-class',

  style: 'display:none'

}, 'Hello, world!');

2.1.3 Function Arguments

When possible, all function arguments should be listed on the same line. If doing so would exceed the 80-column limit, the arguments must be line-wrapped in a readable way. To save space, you may wrap as close to 80 as possible, or put each argument on its own line to enhance readability. The indentation may be either four spaces, or aligned to the parenthesis.

2.1.4 Passing Anonymous Functions

When declaring an anonymous function in the list of arguments for a function call, the body of the function is indented two spaces from the left edge of the statement, or two spaces from the left edge of the function keyword. This is to make the body of the anonymous function easier to read (i.e. not be all squished up into the right half of the screen).

prefix.something.reallyLongFunctionName('whatever', function(a1, a2) {

  if (a1.equals(a2)) {

    someOtherLongFunctionName(a1);

  } else {

    andNowForSomethingCompletelyDifferent(a2.parrot);

  }

});



var names = prefix.something.myExcellentMapFunction(

    verboselyNamedCollectionOfItems,

    function(item) {

      return item.name;

    });

2.1.5 More Indentation

In fact, except for array and object initializers , and passing anonymous functions, all wrapped lines should be indented either left-aligned to the expression above, or indented four spaces, not indented two spaces.

someWonderfulHtml = '' +

                    getEvenMoreHtml(someReallyInterestingValues, moreValues,

                                    evenMoreParams, 'a duck', true, 72,

                                    slightlyMoreMonkeys(0xfff)) +

                    '';



thisIsAVeryLongVariableName =

    hereIsAnEvenLongerOtherFunctionNameThatWillNotFitOnPrevLine();



thisIsAVeryLongVariableName = 'expressionPartOne' + someMethodThatIsLong() +

    thisIsAnEvenLongerOtherFunctionNameThatCannotBeIndentedMore();



someValue = this.foo(

    shortArg,

    'Some really long string arg - this is a pretty common case, actually.',

    shorty2,

    this.bar());



if (searchableCollection(allYourStuff).contains(theStuffYouWant) &&

    !ambientNotification.isActive() && (client.isAmbientSupported() ||

                                        client.alwaysTryAmbientAnyways())) {

  ambientNotification.activate();

}

2.1.6 Binary and Ternary Operators

Always put the operator on the preceding line, so that you don't have to think about implicit semi-colon insertion issues. Otherwise, line breaks and indentation follow the same rules as in other Google style guides.

var x = a ? b : c;  // All on one line if it will fit.



// Indentation +4 is OK.

var y = a ?

    longButSimpleOperandB : longButSimpleOperandC;



// Indenting to the line position of the first operand is also OK.

var z = a ?

        moreComplicatedB :

        moreComplicatedC;

2.2 Strings

Prefer ' over "

For consistency single-quotes (') are preferred to double-quotes ("). This is helpful when creating strings that include HTML.

2.3 JavaScript Types

 

2.3.1 Type Casts

In cases where type-checking doesn't accurately infer the type of an expression, it is possible to add a type cast comment by adding a type annotation comment and enclosing the expression in parentheses. The parentheses are required, and may surround the type annotation comment as well.

/** @type {number} */ (x)

(/** @type {number} */ x)

2.4 Comments

 

2.4.1 JSDoc Indentation

If you have to line break a block tag, you should treat this as breaking a code statement and indent it four spaces.

/**

 * Illustrates line wrapping for long param/return descriptions.

 * @param {string} foo This is a param with a description too long to fit in

 *     one line.

 * @return {number} This returns something that has a description too long to

 *     fit in one line.

 */

project.MyClass.prototype.method = function(foo) {

  return 5;

};

2.4.2 Top/File-Level Comments

The top level comment is designed to orient readers unfamiliar with the code to what is in this file. It should provide a description of the file's contents, its author(s), and any dependencies or compatibility information. As an example:

// Copyright 2009 Google Inc. All Rights Reserved.



/**

 * @fileoverview Description of file, its uses and information

 * about its dependencies.

 * @author user@google.com (Firstname Lastname)

 */

---

Post by: Jalen Wang (转载请注明出处)