JavaScript Style Guide | Contribute to jQuery (original) (raw)

JavaScript Style Guide

• Linting
• Spacing
  • Bad Examples
  • Good Examples
  • Object and Array Expressions
  • Multi-line Statements
  • Chained Method Calls
  • Full File Closures
• Constructors
• Equality
• Type Checks
• Comments
• Quotes
• Semicolons
• Naming Conventions
• Global Variables
• DOM Node Rules
• Switch Statements

link Linting

Use JSHint to detect errors and potential problems. Every jQuery project has a Grunt task for linting all JavaScript files: grunt jshint. The options for JSHint are stored in a .jshintrc file; many repositories will have multiple .jshintrc files based on the type of code in each directory.

Each .jshintrc file follows a specific format. All options must be alphabetized and grouped:

| 1 2 3 4 5 6 7 8 9 10 11 12 | | | -------------------------- | |

The following common options must be used in all projects:

| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | | | -------------------------------- | |

If the project supports browsers which do not implement ES5, then the es3 option must be included with the repo-specific options.

link Spacing

In general, the jQuery style guide encourages liberal spacing for improved human readability. The minification process creates a file that is optimized for browsers to read and process.

• Indentation with tabs.
• No whitespace at the end of line or on blank lines.
• Lines should be no longer than 80 characters, and must not exceed 100 (counting tabs as 4 spaces). There are 2 exceptions, both allowing the line to exceed 100 characters:
  • If the line contains a comment with a long URL.
  • If the line contains a regex literal. This prevents having to use the regex constructor which requires otherwise unnecessary string escaping.
• if/else/for/while/try always have braces and always go on multiple lines.
• Unary special-character operators (e.g., !, ++) must not have space next to their operand.
• Any , and ; must not have preceding space.
• Any ; used as a statement terminator must be at the end of the line.
• Any : after a property name in an object definition must not have preceding space.
• The ? and : in a ternary conditional must have space on both sides.
• No filler spaces in empty constructs (e.g., {}, [], fn())
• New line at the end of each file.
• If the entire file is wrapped in a closure, the function body is not indented. See full file closures for examples.

link Bad Examples

link Good Examples

link Object and Array Expressions

Object and array expressions can be on one line if they are short (remember the line length limits). When an expression is too long to fit on one line, there must be one property or element per line, with the opening and closing braces each on their own lines. Property names only need to be quoted if they are reserved words or contain special characters:

link Multi-line Statements

When a statement is too long to fit on one line, line breaks must occur after an operator.

Lines should be broken into logical groups if it improves readability, such as splitting each expression of a ternary operator onto its own line even if both will fit on a single line.

When a conditional is too long to fit on one line, successive lines must be indented one extra level to distinguish them from the body.

link Chained Method Calls

When a chain of method calls is too long to fit on one line, there must be one call per line, with the first call on a separate line from the object the methods are called on. If the method changes the context, an extra level of indentation must be used.

link Full File Closures

When an entire file is wrapped in a closure, the body of the closure is not indented.

The same applies to AMD wrappers.

For UMD, the factory is indented to visually differentiate it from the body.

link Constructors

Constructor functions should always be invoked with argument lists, even when such lists are empty.

| 1 2 | when = time || new Date(); | | --- | --------------------------- |

When property access or method invocation is immediately performed on the result of a constructor function, clarify precedence with wrapping parentheses.

link Equality

Strict equality checks (===) must be used in favor of abstract equality checks (==). The only exception is when checking for undefined and null by way of null. The use of == null is also acceptable in cases where only one of null or undefined may be logically encountered, such as uninitialized variables.

link Type Checks

• String: typeof object === "string"
• Number: typeof object === "number"
• Boolean: typeof object === "boolean"
• Object: typeof object === "object"
• Plain Object: jQuery.isPlainObject( object )
• Function: jQuery.isFunction( object )
• Array: jQuery.isArray( object )
• Element: object.nodeType
• null: object === null
• null or undefined: object == null
• undefined:
  • Global Variables: typeof variable === "undefined"
  • Local Variables: variable === undefined
  • Properties: object.prop === undefined

Comments are always preceded by a blank line. Comments start with a capital first letter, but don't require a period at the end, unless you're writing full sentences. There must be a single space between the comment token and the comment text.

Single line comments go over the line they refer to:

Multi-line comments are only used for file and function headers.

Inline comments are allowed as an exception when used to annotate special arguments in formal parameter lists or when needed to support a specific development tool:

Do not write API documentation in comments. API documentation lives in its own repository.

link Quotes

jQuery uses double quotes.

Strings that require inner quoting must use double outside and single inside.

link Semicolons

Use them. Never rely on ASI.

link Naming Conventions

Variable and function names should be full words, using camel case with a lowercase first letter. Names should be descriptive but not excessively so. Exceptions are allowed for iterators, such as the use of i to represent the index in a loop. Constructors do not need a capital first letter.

link Global Variables

Each project may expose at most one global variable.

link DOM Node Rules

.nodeName must always be used in favor of .tagName.

.nodeType must be used to determine the classification of a node (not .nodeName).

link Switch Statements

The usage of switch statements is generally discouraged, but can be useful when there are a large number of cases - especially when multiple cases can be handled by the same block, or fall-through logic (the default case) can be leveraged.

When using switch statements:

• Use a break for each case other than default.
• Align case statements with the switch.