Functions

Three ways to write one

Same function, three spellings — and the differences between them aren't cosmetic. They change when the function exists and what it's allowed to do.

// 1. Declaration — a named statement
function add(a, b) {
  return a + b;
}

// 2. Expression — a value, happens to be a function, assigned like any other
const subtract = function (a, b) {
  return a - b;
};

// 3. Arrow — an expression too, but lighter and with no own "this"
const multiply = (a, b) => a * b;

console.log(declared());     // what happens?
function declared() { return "I work before my own definition"; }

console.log(typeof viaVar);  // what happens?
viaVar();
var viaVar = function () { return "x"; };

declared() works — function declarations are hoisted completely: name and body, both ready before line 1 runs. viaVar is different: var hoists the name (pre-filled with undefined) but not the function it's later assigned. So typeof viaVar is "undefined", and calling it throws TypeError: viaVar is not a function — you're calling undefined(). Swap var for const and it's worse: a ReferenceError, because the name sits in the Temporal Dead Zone until its line runs.

Arrow functions — the concise cousin

Arrows drop the function keyword and, with exactly one parameter, the parentheses too. A one-expression body skips return entirely — the expression's value is the return value.

const square = n => n * n;                  // implicit return
const clamp = (n, lo, hi) => Math.min(Math.max(n, lo), hi);
const noisy = n => {                          // block body needs an explicit return
  console.log("squaring", n);
  return n * n;
};

The bigger difference isn't syntax, it's this and arguments. An arrow doesn't create either — it reads through to whatever function it's lexically written inside:

function outer(a, b) {
  const arrow = (x, y, z) => arguments.length;
  return arrow(1, 2, 3);
}
console.log(outer(10, 20));   // what happens?

2, not 3. The arrow's arguments isn't its own — it's outer's, which was called with two values. The same logic governs this inside an arrow, and it's the whole reason arrows became the default choice for callbacks: no more const self = this; workaround. The full mechanics of this get their own chapter later — for now, remember arrows borrow it rather than own it.

Dry run: the call stack, and whose arguments gets read

The three arguments passed to arrow are never read at all — an arrow function doesn't get its own arguments object to shadow the outer one, so the lookup walks straight past it to the nearest function that does: outer.

Parameters, arguments, defaults

A parameter is the name in the function's own definition. An argument is the actual value handed over at the call site. Extra arguments are silently dropped; missing ones become undefined — unless a default says otherwise.

function greet(name, greeting = "Hello") {
  return greeting + ", " + name + "!";
}
greet("Ana");              // "Hello, Ana!"
greet("Ana", "Hi");        // "Hi, Ana!"
greet("Ana", undefined);   // "Hello, Ana!" — undefined also triggers the default

Defaults aren't static values baked in once — they're expressions, evaluated fresh on every call that needs them, and they can reference earlier parameters:

function withDefault(a, b = a + 1) {
  return b;
}
console.log(withDefault(5));       // what happens?
console.log(withDefault(5, 100));  // what happens?

6, then 100 — the default only runs when the argument is missing (or explicitly undefined); supply anything else and the default expression never executes at all.

Rest parameters — the modern arguments

...args in a parameter list collects every remaining argument into a real array — unlike the old arguments object, which looks array-ish but has no map/filter/reduce of its own. Arrows don't get arguments at all, so rest params are their only option for "however many args you send me."

function sum(...nums) {
  return nums.reduce((total, n) => total + n, 0);
}
sum(1, 2, 3, 4);   // 10

function logAll(label, ...rest) {   // rest must be LAST
  console.log(label, rest);
}

Return — and the newline that eats it

No return statement, or a bare return;, both give back undefined. That's not the interesting part — this is:

function makeUser() {
  return
  { name: "Ana" };
}
console.log(makeUser());   // what happens?

undefined — not the object. Automatic Semicolon Insertion sees a line break right after return and quietly inserts a semicolon there, turning it into return; followed by an unreachable, orphaned block. The object literal on the next line never has a chance to be returned.

Where a function's variables live

Every call gets its own scope: variables declared inside are invisible outside, and a nested function can see everything around it, never the reverse.

function outer() {
  let secret = 42;
  function inner() {
    console.log(secret);   // fine — inner can see outer's variables
  }
  inner();
}
console.log(typeof secret);   // "undefined" — outer can't be seen from here

That is Scope applied to functions — the lookup, shadowing, and why a function sees where it was written rather than where it was called are all there. What is new in this chapter is the part only functions have: parameters.

Hoisting, one level up

The Temporal Dead Zone from the execution context chapter applies the same way inside a function body. Parameters add one rule on top: they are created when the call starts and initialised left to right, each one ready before the next default runs. That is why b = a + 1 works and a = b throws, as shown above.

function rename(x) {
  let y = x;     // fine — a new name
}

function clash(x) {
  let x = 1;     // SyntaxError: Identifier 'x' has already been declared
}

function nested(x) {
  if (x) {
    let x = "inner";   // allowed — a new block, so this shadows the parameter
  }
}

A parameter and a let/const of the same name can't coexist in the function's top-level scope — JS won't let you silently replace an argument you probably still needed. Inside a nested block the new name is fine, and the parameter is visible again once the block ends.

What comes next

This is the mechanical half: how to write one, what the parameters do, where the name lives. The half that interviews spend their time on comes next: this with its four binding rules and call / apply / bind, then closures, and at the intermediate level currying, composition and recursion in Scope & functions, properly. Nothing here is superseded there; it is the same subject, one layer down.