JS Code style Guide

I. BASIC format

1. Indent in

   Recommended 4 spaces per level, can be set to the editor tab = 4 spaces, automatic conversion

2. Semicolon

   Do not omit the semicolon to prevent the ASI (auto-insert semicolon) error

3. Line width

   Each line of code is less than 80 characters long and should be manually separated by an operator

4. Break

   The operator is at the end of the previous line, and the next line is indented level 2, and if it is an assignment statement, it should also be aligned to the back part of the equals sign

5. Blank Line

   function declarations and function declarations, variable declarations and function declarations, and logical blocks inside functions should be separated by a blank line

   Author Nicholas also suggested leaving a blank line at the top of the process control block, but the example given is not very clear

6. Named

   • Variable name/function name: Camel (Hump) rule, first letter lowercase, follow-up letter uppercase, remainder lowercase

   • Constant Name: C language, all caps, underline participle

   • Constructors: Pascal rules, all words capitalized, the remainder lowercase

7. Literal quantity

   • String: Double quote wrap, break with [+] operator, do not use \ Escape character

   • Value: do not omit the part before or after the decimal point, do not use the octal form

   • NULL: Use NULL as a placeholder for object only, not to detect parameters, nor to detect uninitialized variables

   • Undefined: All objects should be initialized to null to differentiate between undefined and non-initialized

   • Object literal/array literal: do not declare objects and arrays in constructor form

Two. Notes

P.s. There is a very classical explanation in the book:

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

1. Single-line Comment

   • End of line: Use 1-level indentation to separate code, and//to have a space behind

   • Exclusive line: Used to comment below, to keep the same indentation as the commented code

   • Beginning of line: used to annotate multiple lines of code

2. Multi-line comments

   Used to wrap large pieces of notes and recommend the Eclipse style, such as

   code/*  * Comment line1 * Comment line2 * *

   Attention:

   • Leave a blank line above the multiline comment

   • * Leave a space behind the asterisk

   • Multiline comment At least three lines (since the first and last lines are not annotated)

3. Where to add comments

   • Code that cannot be self-explanatory

   • Deliberately, but it looks like a mistake.

   • Browser-specific hack

4. Document comments

   Each function should be annotated, including feature descriptions, parameters, return values, thrown errors, and so on, such as the recommended Eclipse style:

   /** * Add the specified element to the default array *  * @method Add * @param {number} The element to be added * @return {Boolean} Add success/failure * @throw {TypeError} parameter type mismatch * /function Add (item) {    if (typeof item = = = "Number") {        Arr.push (item)    }    else{        throw new TypeError () ;    }}

Three. Statements and expressions

1. Curly Brace Alignment

   Recommended line end style, do not recommend the second line style

2. Block statement spaces

   The parentheses after the if section have a space before and after it, for example:

   if (expr) {    code}

3. Switch statement

   • Indent: Case is aligned with switch, break indent level 1

   • Case runs through: using blank lines or annotations//falls through to indicate that case penetration is intentional

   • Default: Keep default or comment//no default indicates no default

   P.S, author of the best JavaScript language, Douglas argues that it should not be a case-by-case (called a chicken-ribs), because it is easy to trigger a bug, and Nicholas thinks it's good to use a blank line or a note.

4. With statement

   No

5. For loop

   All variables should be declared at the top of the function body, including variables used by the For Loop initialization section, to avoid hosting (elevation) causing a bug (global variables may be masked)

6. For-in Cycle

   do not use to iterate over the array, use the time to remember to add hasownproperty filter, if you deliberately traverse the prototype properties, should be annotated

Four. Variables, functions, operators

1. Variable declaration

   function BODY = variable declaration + function declaration + logical statement. Separate sections with blank lines

2. function declaration

   Declare the reuse, and do not put the function declaration in the IF branch, because the browser understands the difference, and ES does not give the standard

3. Function call

   do not add spaces around the parentheses to avoid confusion with block statements

4. Anonymous functions execute immediately

   Enclose the immediately executing anonymous function in parentheses to avoid confusion with anonymous function declarations

5. Strict mode

   do not open strict mode in the global scope, only inside the function, open to multiple functions can use anonymous function immediately to perform the scope of qualified strict mode

6. Judgment equals

   Use only = = = and!==

7. Eval

   Use an anonymous function to optimize settimeout () and setinterval () without eval () and new function ()

8. Basic Package Type

   do not use new Boolean (), New String (), new number ()

Resources

• "Maintainable JavaScript"

• The essence of JavaScript language

JS Code style Guide