4.6 Whitespace

4.6.1 Vertical whitespace

A single blank line appears:

• Between consecutive methods in a class or object literal
  • Exception: A blank line between two consecutive properties definitions inan object literal (with no other code between them) is optional. Suchblank lines are used as needed to create logical groupings of fields.
• Within method bodies, sparingly to create logical groupings of statements.Blank lines at the start or end of a function body are not allowed.
• Optionally before the first or after the last method in a class or objectliteral (neither encouraged nor discouraged).
• As required by other sections of this document (e.g.??).Multiple consecutive blank lines are permitted, but never required (norencouraged).

4.6.2 Horizontal whitespace

Use of horizontal whitespace depends on location, and falls into three broadcategories: leading (at the start of a line), trailing (at the end of aline), and internal. Leading whitespace (i.e., indentation) is addressedelsewhere. Trailing whitespace is forbidden.

Beyond where required by the language or other style rules, and apart fromliterals, comments, and JSDoc, a single internal ASCII space also appears in thefollowing places only.

• Separating any reserved word (such as if, for, or catch) except forfunction and super, from an open parenthesis (() that follows it onthat line.
• Separating any reserved word (such as else or catch) from a closingcurly brace (}) that precedes it on that line.
• Before any open curly brace ({), with two exceptions:
  • Before an object literal that is the first argument of a function or thefirst element in an array literal (e.g. foo({a: [{c: d}]})).
  • In a template expansion, as it is forbidden by the language (e.g. valid:ab${1 + 2}cd, invalid: xy$ {3}z).
• On both sides of any binary or ternary operator.
• After a comma (,) or semicolon (;). Note that spaces are never allowedbefore these characters.
• After the colon (:) in an object literal.
• On both sides of the double slash (//) that begins an end-of-line comment.Here, multiple spaces are allowed, but not required.
• After an open-block comment character and on both sides of close characters(e.g. for short-form type declarations, casts, and parameter name comments:this.foo = / @type {number} */ (bar); or function(/ string / foo){; or baz(/ buzz= */ true)).

4.6.3 Horizontal alignment: discouraged

Terminology Note: Horizontal alignment is the practice of adding avariable number of additional spaces in your code with the goal of makingcertain tokens appear directly below certain other tokens on previous lines.

This practice is permitted, but it is generally discouraged by GoogleStyle. It is not even required to maintain horizontal alignment in placeswhere it was already used.

Here is an example without alignment, followed by one with alignment. Both areallowed, but the latter is discouraged:

{
  tiny: 42, // this is great
  longer: 435, // this too
};
{
  tiny:   42,  // permitted, but future edits
  longer: 435, // may leave it unaligned
};

Tip: Alignment can aid readability, but it creates problems for futuremaintenance. Consider a future change that needs to touch just one line. Thischange may leave the formerly-pleasing formatting mangled, and that isallowed. More often it prompts the coder (perhaps you) to adjust whitespace onnearby lines as well, possibly triggering a cascading series ofreformattings. That one-line change now has a blast radius. This can at worstresult in pointless busywork, but at best it still corrupts version historyinformation, slows down reviewers and exacerbates merge conflicts.

4.6.4 Function arguments

Prefer to put all function arguments on the same line as the function name. 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. Indentation should be four spaces. Aligning to the parenthesis is allowed, but discouraged. Below are the most common patterns for argument wrapping:

// Arguments start on a new line, indented four spaces. Preferred when the
// arguments don't fit on the same line with the function name (or the keyword
// "function") but fit entirely on the second line. Works with very long
// function names, survives renaming without reindenting, low on space.
doSomething(
    descriptiveArgumentOne, descriptiveArgumentTwo, descriptiveArgumentThree) {
  // …
}
// If the argument list is longer, wrap at 80. Uses less vertical space,
// but violates the rectangle rule and is thus not recommended.
doSomething(veryDescriptiveArgumentNumberOne, veryDescriptiveArgumentTwo,
    tableModelEventHandlerProxy, artichokeDescriptorAdapterIterator) {
  // …
}
// Four-space, one argument per line.  Works with long function names,
// survives renaming, and emphasizes each argument.
doSomething(
    veryDescriptiveArgumentNumberOne,
    veryDescriptiveArgumentTwo,
    tableModelEventHandlerProxy,
    artichokeDescriptorAdapterIterator) {
  // …
}