Functions

​

Functions

​

7.1 Use named function expressions

Function declarations are hoisted, which means it’s easy — too easy — to reference the function before it is defined in the file. This harms readability and maintainability. If you find that a function’s definition is large or complex enough that it interferes with understanding the rest of the file, then perhaps it’s time to extract it to its own module. Always explicitly name the expression, regardless of whether or not the name is inferred from the containing variable. This eliminates assumptions made about the Error’s call stack.

// bad
function foo() {
  // ...
}

// bad
const foo = function () {
  // ...
};

// good
// lexical name distinguished from the variable-referenced invocation(s)
const short = function longUniqueMoreDescriptiveLexicalFoo() {
  // ...
};

​

7.2 Wrap IIFEs in parentheses

An immediately invoked function expression is a single unit. Wrapping both it and its invocation parens in parentheses cleanly expresses this. Note that in a world with modules everywhere, you almost never need an IIFE.

// immediately-invoked function expression (IIFE)
(function () {
  console.log('Welcome to the Internet. Please follow me.');
}());

​

7.3 Never declare a function in a non-function block

Browsers will allow you to do it, but they all interpret it differently.

​

7.4 Function declarations are not statements

let test;
if (currentUser) {
  test = () => {
    console.log('Yup.');
  };
}

if (currentUser) {
  function test() {
    console.log('Nope.');
  }
}

​

7.5 Never name a parameter arguments

function foo(name, options, args) {
  // ...
}

function foo(name, options, arguments) {
  // ...
}

​

7.6 Use rest syntax instead of arguments

... is explicit about which arguments you want pulled. Rest arguments are a real Array, not merely Array-like like arguments.

function concatenateAll(...args) {
  return args.join('');
}

function concatenateAll() {
  const args = Array.prototype.slice.call(arguments);
  return args.join('');
}

​

7.7 Use default parameter syntax

// really bad
function handleThings(opts) {
  // No! We shouldn't mutate function arguments.
  // Double bad: if opts is falsy it'll be set to an object which may
  // be what you want but it can introduce subtle bugs.
  opts = opts || {};
  // ...
}

// still bad
function handleThings(opts) {
  if (opts === void 0) {
    opts = {};
  }
  // ...
}

// good
function handleThings(opts = {}) {
  // ...
}

​

7.8 Avoid side effects with default parameters

Default parameters with side effects are confusing to reason about.

let b = 1;
// bad
function count(a = b++) {
  console.log(a);
}
count();  // 1
count();  // 2
count(3); // 3
count();  // 3

​

7.9 Always put default parameters last

function handleThings(name, opts = {}) {
  // ...
}

function handleThings(opts = {}, name) {
  // ...
}

​

7.10 Never use the Function constructor

Creating a function this way evaluates a string similarly to eval(), which opens vulnerabilities.

// bad
const add = new Function('a', 'b', 'return a + b');

// still bad
const subtract = Function('a', 'b', 'return a - b');

​

7.11 Consistent spacing in function signatures

Consistency is good, and you shouldn’t have to add or remove a space when adding or removing a name.

const x = function () {};
const y = function a() {};

const f = function(){};
const g = function (){};
const h = function() {};

​

7.12 Never mutate parameters

Manipulating objects passed in as parameters can cause unwanted variable side effects in the original caller.

function f2(obj) {
  const key = Object.prototype.hasOwnProperty.call(obj, 'key') ? obj.key : 1;
}

function f1(obj) {
  obj.key = 1;
}

​

7.13 Never reassign parameters

Reassigning parameters can lead to unexpected behavior, especially when accessing the arguments object. It can also cause optimization issues, especially in V8.

// bad
function f1(a) {
  a = 1;
  // ...
}

function f2(a) {
  if (!a) { a = 1; }
  // ...
}

// good
function f3(a) {
  const b = a || 1;
  // ...
}

function f4(a = 1) {
  // ...
}

​

7.14 Prefer spread over apply

Spread syntax is cleaner, you don’t need to supply a context, and you can’t easily compose new with apply.

const x = [1, 2, 3, 4, 5];
console.log(...x);

new Date(...[2016, 8, 5]);

const x = [1, 2, 3, 4, 5];
console.log.apply(console, x);

new (Function.prototype.bind.apply(Date, [null, 2016, 8, 5]));

​

7.15 Indent multiline function signatures

function foo(
  bar,
  baz,
  quux,
) {
  // ...
}

console.log(
  foo,
  bar,
  baz,
);

function foo(bar,
             baz,
             quux) {
  // ...
}

console.log(foo,
  bar,
  baz);