1. Basic Format

Indentation

It is recommended to use 4 spaces per level. You can set tab = 4 spaces in the editor for automatic conversion.

Semicolons

Do not omit semicolons to prevent ASI (Automatic Semicolon Insertion) errors.

Line width

Each line of code should not exceed 80 characters. If it is too long, use operators to manually break the line.

Line breaks

The operator should be at the end of the previous line, and the next line should be indented 2 levels. If it is an assignment statement, it should also be aligned with the part after the equals sign.

Blank lines

Blank lines should be used to separate function declarations from function declarations, variable declarations from function declarations, and logical blocks within a function.

The author Nicholas also suggests leaving a blank line at the top of flow control blocks, but the example given is not very clear.

Naming

  • Variable names/function names: Camel rule, the first word starts with a lowercase letter, subsequent words start with uppercase letters, and the rest are lowercase.
  • Constant names: C-style, all uppercase, words separated by underscores.
  • Constructors: Pascal rule, all words start with uppercase letters, and the rest are lowercase.

Literals

  • Strings: wrapped in double quotes, use the [+] operator for line breaks, do not use the \ escape character.
  • Numbers: do not omit the parts before and after the decimal point, and do not use octal form.
  • Null: only treat null as a placeholder for Object. Do not use it to check parameters, and do not use it to check uninitialized variables.
  • Undefined: all objects should be initialized to null to distinguish undefined from uninitialized.
  • Object literals/Array literals: do not use the constructor approach to declare objects and arrays.

2. Comments

P.S. There is a very classic explanation in the book:

Appropriately written comments help tell the story of code, allowing other developers to drop into a part of the story without needing to hear the beginning.

Single-line comments

  • End of line: separate from code with 1 level of indentation, and there should be a space after //.
  • On its own line: used to comment the code below, and it should maintain the same indentation as the commented code.
  • Start of line: used to comment multiple lines of code.

Multi-line comments

Used to wrap large blocks of comments. The Eclipse style is recommended, for example

/*
 * comment line1
 * comment line2
 */

Note:

  • Leave a blank line above multi-line comments.
  • Leave a space after the * asterisk.
  • Multi-line comments should have at least three lines (because no comments are added after the first and last lines).

Where to add comments

  • Code that cannot self-explain
  • Intentional but looks like it has errors
  • Browser-specific hacks

Documentation comments

Comments should be added to each function, including description, parameters, return value, thrown errors, etc., for example, the recommended Eclipse style:

/**
 * 添加指定元素到默认数组
 *
 * @method add
 * @param {Number} 将要添加的元素
 * @return {Boolean} 添加成功/失败
 * @throw {TypeError} 参数类型不匹配
 */
function add(item){
    if(typeof item === "number"){
        arr.push(item)
    }
    else{
        throw new TypeError();
    }
}

3. Statements and Expressions

Brace alignment

The end-of-line style is recommended, not the next-line style.

Block statement spacing

There should be a space before and after the parentheses after if, for example:

if (expr) {
    code
}

switch statement

  • Indentation: case is aligned with switch, break is indented 1 level.
  • Case fall-through: use a blank line or the comment //falls through to indicate that the fall-through is intentional.
  • default: keep default or use the comment //no default to indicate that there is no default.

P.S. Douglas, the author of "JavaScript: The Good Parts", believes that case fall-through should not be used (calling it "chicken ribs" - something of little value), while Nicholas thinks it is fine as long as it is explained with a blank line or a comment.

with statement

Do not use it.

for loop

All variables should be declared at the top of the function body, including variables used in the for loop initialization part, to avoid bugs caused by hoisting (which may shadow global variables).

for-in loop

Do not use it to iterate over arrays. When using it, remember to add the hasOwnProperty filter. If you intentionally iterate over prototype properties, you should explain it with a comment.

4. Variables, Functions, Operators

Variable declarations

Function body = variable declarations + function declarations + logic statements. Separate each part with blank lines.

Function declarations

Declare before use. Never put function declarations inside if branches, because browsers understand them differently, and ES does not provide a standard.

Function calls

Do not add spaces before or after the parentheses, to avoid confusion with block statements.

Immediately invoked anonymous functions

Wrap immediately invoked anonymous functions in parentheses to avoid confusion with anonymous function declarations.

Strict mode

Do not enable strict mode in the global scope. Only enable it inside functions. To enable it for multiple functions, you can use an immediately invoked anonymous function to limit the scope of strict mode.

Equality check

Only use === and !==.

eval

Do not use eval() and new Function(). Use anonymous functions to optimize setTimeout() and setInterval().

Primitive wrapper types

Do not use new Boolean(), new String(), new Number().

References

  • 《Maintainable JavaScript》
  • "JavaScript: The Good Parts"

From: http://www.codeceo.com/article/javascript-code-style-guide.html