Three ways to write a function

A function declaration starts with the keyword function and a name. A function expression creates a function as a value and stores it in a variable. An arrow function is a shorter expression. All three can do the same job:

function lineTotal(qty, unitPrice) { return qty * unitPrice; }           // declaration
const lineTotal2 = function (qty, unitPrice) { return qty * unitPrice; }; // expression
const lineTotal3 = (qty, unitPrice) => qty * unitPrice;                  // arrow

// Default values and a rest parameter
function receiptLine(articleCode, qty = 1, ...notes) {
  return `${articleCode} x${qty}${notes.length ? ' (' + notes.join(', ') + ')' : ''}`;
}
console.log(lineTotal(2, 1250), lineTotal2(2, 1250), lineTotal3(2, 1250));
console.log(receiptLine('100234'));
console.log(receiptLine('100234', 3, 'festival offer', 'gift wrap'));
console.log(receiptLine('100234', undefined));   // undefined triggers the default
console.log(receiptLine('100234', null));        // null does not
console.log(lineTotal(2));                       // a missing argument is undefined

const toObj = (siteId) => ({ siteId });          // returning an object: wrap it in ( )
const broken = (siteId) => { siteId };           // braces mean a body; returns nothing
console.log(toObj('S014'), broken('S014'));

2500 2500 2500
100234 x1
100234 x3 (festival offer, gift wrap)
100234 x1
100234 xnull
NaN
{ siteId: 'S014' } undefined

Four details from that output matter in real code. A default value is used only when the argument is undefined, so an API that sends null skips it. A missing argument does not cause an error; it is undefined, and 2 * undefined is NaN. The rest parameter ...notes collects the extra arguments into a real array. And an arrow function returns its expression automatically only when there are no braces, so an object literal must be wrapped in parentheses.

Which to use? Teams usually write top-level, named helpers as declarations or const arrows (both are fine; pick one in the style guide), and use arrows for short callbacks such as sales.map((s) => s.qty). Arrow functions also differ in one big way: they have no this of their own. That is covered below, and it is the reason arrows are the right choice for callbacks inside methods.

Scope: where a name is visible

Scope is the region of code where a name can be used. JavaScript has three kinds you meet every day. Block scope: let and const inside { } of an if, a loop or a bare block exist only there. Function scope: parameters and variables declared in a function exist only during that call. Module scope: top-level names in a file are visible to the whole file, and to other files only if you export them (Prototypes, classes and modules).

Scopes nest, and lookup always goes outward, never inward. When code uses a name, JavaScript looks in the current block first, then the enclosing function, then the module, then the global scope. The first match wins. If nothing matches, you get a ReferenceError. Outer code can never see names declared inside an inner block.

const storeName = 'Riverside';            // module scope: the whole file sees it

function closeShift(sales) {
  let total = 0;                          // function scope: only inside closeShift
  for (const sale of sales) {
    const line = sale.qty * sale.unitPrice;   // block scope: only inside the loop body
    total += line;                        // "total" is found one scope outward
  }
  try { console.log(line); }              // outside the block: not visible
  catch (e) { console.log(e.name + ': ' + e.message); }
  return `${storeName}: ${total} cents`;  // "storeName" is found two scopes out
}
console.log(closeShift([{ qty: 2, unitPrice: 1250 }, { qty: 1, unitPrice: 450 }]));

if (true) { var leaky = 'var ignores blocks'; let tight = 'let respects blocks'; }
console.log(leaky, typeof tight);

ReferenceError: line is not defined
Riverside: 2950 cents
var ignores blocks undefined

The last two lines show why var is banned: it belongs to the whole function (or the whole script), so it leaks out of the if block. let stays where it was declared.

Hoisting and the temporal dead zone

Before any line of a scope runs, JavaScript scans the scope and creates every name declared in it. This is called hoisting. What differs is the state each name starts in:

• A function declaration is created complete, so you can call it above the line where it is written.
• A var is created with the value undefined, so reading it early gives undefined without any error. That silence hides bugs.
• A let, const or class is created but left uninitialised. From the top of the scope until its declaration line runs, it is in the temporal dead zone (TDZ), and touching it throws a ReferenceError.

console.log(addTax(1000));           // works: a function declaration is ready early
console.log(oldStyle);               // var exists early, but is undefined

try { console.log(total); }          // let exists, but is in the dead zone
catch (e) { console.log(e.name + ': ' + e.message); }

try { console.log(formatUsd(5000)); }    // a const arrow function: same dead zone
catch (e) { console.log(e.name + ': ' + e.message); }

function addTax(cents) { return cents + Math.round(cents * 0.15); }
var oldStyle = 'set now';
let total = 0;
const formatUsd = (cents) => `USD ${(cents / 100).toFixed(2)}`;

1150
undefined
ReferenceError: Cannot access 'total' before initialization
ReferenceError: Cannot access 'formatUsd' before initialization

The message "Cannot access … before initialization" is the TDZ. The message "… is not defined" means the name does not exist in any enclosing scope at all. Knowing which one you are looking at tells you whether the problem is order or spelling.

Closures: a function keeps its scope alive

Each time a function runs, JavaScript creates a fresh set of its local variables, called its environment. Normally that environment is thrown away when the call returns. But if the call creates an inner function that uses those variables, and the inner function survives (it is returned, stored, or passed as a callback), then the environment survives too. The inner function plus the variables it keeps is a closure.

function makeTokenCounter(prefix) {
  let next = 1;                            // survives after makeTokenCounter returns
  return function issue() {
    const token = `${prefix}-${String(next).padStart(3, '0')}`;
    next += 1;
    return token;
  };
}
const counter1 = makeTokenCounter('C1');   // two calls, two separate "next" variables
const counter2 = makeTokenCounter('C2');
console.log(counter1(), counter1(), counter2(), counter1());

function makePriceFormatter(currency, decimals) {
  return (cents) => `${currency} ${(cents / 100).toFixed(decimals)}`;
}
const usd = makePriceFormatter('USD', 2);
const usdWhole = makePriceFormatter('USD', 0);
console.log(usd(1250), usdWhole(1250));

C1-001 C1-002 C2-001 C1-003
USD 12.50 USD 13

Three facts explain that output. The closure keeps the variable itself, not a copy of its value, which is why next keeps going up. Each call to the outer function makes a new environment, so counter2 starts again at 1. And the variable is private: no code outside can read or reset next, because no outside scope contains it. That is how JavaScript did private state for about twenty years before classes got #private fields (Prototypes, classes and modules).

this: decided by the call, unless it is an arrow

Inside a normal function or method, this is not fixed when you write the function. It is decided each time the function is called, by how it is called. Call it as store.label() and this is store. Copy the same function into a variable and call label(), and this is undefined in strict mode (which ES modules and classes always use). In an old non-strict script it is worse: this becomes the global object, and your code writes to globals without any error.

An arrow function has no this of its own. It uses the this of the scope it was written in, exactly like any other outer variable. That makes arrows the right tool for callbacks inside methods, and the wrong tool for the methods themselves.

// this-lost.mjs
const store = {
  siteId: 'S014',
  label() { return `Store ${this.siteId}`; },
};
console.log(store.label());                  // called on store: this = store
const label = store.label;                   // the same function, cut off
try { label(); } catch (e) { console.log(e.name + ': ' + e.message); }
const bound = store.label.bind(store);       // bind fixes "this" for good
console.log(bound());

Store S014
TypeError: Cannot read properties of undefined (reading 'siteId')
Store S014

Passing a method as a callback, as in rows.map(this.toDto) or button.onPress = this.save, is the same as cutting it off: the receiver does not call it on your object. Wrap it in an arrow (rows.map((r) => this.toDto(r))) or bind it.

Higher-order and pure functions

In JavaScript a function is a value: you can pass it in, return it, and keep it in an array. A higher-order function takes a function, returns one, or both. You already use them: sales.filter((s) => !s.voided) passes a function to filter. The factories above return one.

A pure function gives the same output for the same input and changes nothing outside itself. (total, sale) => total + sale.qty * sale.unitPrice is pure. A function that adds to a module-level todayTotal is not: calling it twice with the same sale gives two different answers. Pure functions are easy to test (no setup, no mocks), safe to cache, and safe to run in any order. Keep pricing, discount and tax rules pure, and push the impure parts (reading the database, writing logs, sending the receipt by text message) to the edges of the code.