
Functions are the primary unit of reuse in JavaScript. How you declare them affects hoisting, `this` binding, and readability.

<ExamplePair>
<ExampleProse>

A **function declaration** is hoisted - the name and body are available before the line they appear on. A **function expression** is only available after the assignment is evaluated.

</ExampleProse>
<ExampleCode>

```js
// declaration - works before its definition line
greet("World"); // Hello, World

function greet(name) {
  console.log("Hello, " + name);
}

// expression - not hoisted; calling it before this line throws
const farewell = function (name) {
  console.log("Goodbye, " + name);
};
farewell("World"); // Goodbye, World
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Default parameters provide fallback values when an argument is `undefined`. They are evaluated at call time, not definition time.

</ExampleProse>
<ExampleCode>

```js
function connect(host = "localhost", port = 5432) {
  console.log(`${host}:${port}`);
}

connect();               // localhost:5432
connect("db.prod", 5433); // db.prod:5433
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

The rest parameter (`...args`) collects all remaining arguments into a real array. It must be the last parameter.

</ExampleProse>
<ExampleCode>

```js
function sum(first, ...rest) {
  return rest.reduce((acc, n) => acc + n, first);
}

console.log(sum(1, 2, 3, 4)); // 10
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`this` inside a regular function is determined at call time - it is the object the function is called on, not where it was defined.

</ExampleProse>
<ExampleCode>

```js
const counter = {
  count: 0,
  increment() {
    this.count++;
    console.log(this.count);
  },
};

counter.increment(); // 1

const fn = counter.increment;
fn(); // TypeError in strict mode (this is undefined); NaN in sloppy mode (this is globalThis)
```

</ExampleCode>
</ExamplePair>

<InProduction>
Positional parameters past two or three make call-sites unreadable: `createUser("Ana", true, false, null, 3)` - what does each boolean mean? Destructure an options object instead: `createUser({ name, admin, verified, role, retries })`. It survives parameter reordering, makes call-sites self-documenting, and lets callers omit optional fields cleanly. Flag it in code review when you see more than three positional args.
</InProduction>


Declaration vs expression, hoisting, default params, rest params, and dynamic `this`.

Functions


Arrow functions are a compact function syntax that captures `this` from the surrounding scope instead of binding it dynamically.

<ExamplePair>
<ExampleProse>

The basic arrow syntax removes the `function` keyword. Parentheses around a single parameter are optional; a single-expression body can omit braces and `return`.

</ExampleProse>
<ExampleCode>

```js
// Traditional expression
const double = function (n) {
  return n * 2;
};

// Arrow - equivalent
const triple = (n) => n * 3;

// Multi-statement body still needs braces and return
const clamp = (n, min, max) => {
  if (n < min) return min;
  if (n > max) return max;
  return n;
};

console.log(double(5));       // 10
console.log(triple(5));       // 15
console.log(clamp(12, 0, 10)); // 10
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Arrow functions capture `this` lexically - from the enclosing scope at definition time, not from the caller. This makes them ideal as callbacks inside methods.

</ExampleProse>
<ExampleCode>

```js
class Timer {
  constructor() {
    this.seconds = 0;
  }

  start() {
    // Arrow function: `this` is the Timer instance
    setInterval(() => {
      this.seconds++;
      console.log(this.seconds);
    }, 1000);
  }
}

// With a regular function, `this` would be undefined (strict mode)
// or the global object - the classic setTimeout/setInterval trap.
const t = new Timer();
t.start(); // 1, 2, 3 ...
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Arrow functions cannot be used as constructors, and they have no `arguments` object. They also cannot be generator functions.

</ExampleProse>
<ExampleCode>

```js
const Foo = () => {};
// new Foo(); // TypeError: Foo is not a constructor

// Arrow functions have no `arguments` - use rest params instead
const sum = (...nums) => nums.reduce((a, b) => a + b, 0);
console.log(sum(1, 2, 3)); // 6
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Object method shorthand (or a regular `function`) is the right choice when the method needs to reference the owning object via `this`. An arrow method silently captures the wrong `this`.

</ExampleProse>
<ExampleCode>

```js
const counter = {
  count: 0,

  // WRONG - arrow captures `this` from module scope, not the object
  badIncrement: () => {
    counter.count++; // forced to reference by name - fragile
  },

  // CORRECT - method shorthand binds `this` to the receiver
  increment() {
    this.count++;
  },
};

counter.increment();
console.log(counter.count); // 1
```

</ExampleCode>
</ExamplePair>

<InProduction>
Arrow functions cannot be used as object methods when the method needs dynamic `this` (the owning object), cannot be constructors, and cannot be generators. Use arrow functions for callbacks, array method predicates, and any inner function that should inherit `this` from the surrounding method. Use the `function` keyword (or method shorthand) for anything that defines its own `this` - class methods, Express route handlers that rely on `this`, and generator functions. Mixing the two up is one of the quietest sources of `undefined is not an object` errors in production.
</InProduction>


Shorter syntax and lexical `this` - plus when arrow functions are the wrong choice.

Arrow Functions


JavaScript offers several loop constructs. Picking the right one matters for correctness, readability, and async behavior.

<ExamplePair>
<ExampleProse>

A classic `for` loop gives full control over the index - useful when you need the position, not just the value.

</ExampleProse>
<ExampleCode>

```js
const items = ["a", "b", "c"];

for (let i = 0; i < items.length; i++) {
  console.log(i, items[i]);
}
// 0 a
// 1 b
// 2 c
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`for-of` iterates over the _values_ of any iterable - arrays, strings, Sets, Maps, and generators. It's the modern default for sequential iteration.

</ExampleProse>
<ExampleCode>

```js
const colors = ["red", "green", "blue"];

for (const color of colors) {
  console.log(color);
}
// red
// green
// blue
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`for-in` iterates over the _keys_ of an object - including enumerable inherited properties. Avoid it on arrays; it can surface unexpected prototype keys and the order is not guaranteed.

</ExampleProse>
<ExampleCode>

```js
const user = { name: "Ana", role: "admin" };

for (const key in user) {
  console.log(key, user[key]);
}
// name Ana
// role admin
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`.forEach` passes each value to a callback but cannot be `break`-ed out of and cannot be awaited. `for-of` is safer in both situations.

</ExampleProse>
<ExampleCode>

```js
const ids = [1, 2, 3];

// WRONG - forEach does not await the async callback
ids.forEach(async (id) => {
  await saveToDb(id); // runs fire-and-forget
});

// CORRECT - sequential async iteration
for (const id of ids) {
  await saveToDb(id);
}

// CORRECT - parallel with bounded result collection
await Promise.all(ids.map((id) => saveToDb(id)));
```

</ExampleCode>
</ExamplePair>

<InProduction>
The `forEach` + `async` trap is one of the most common async bugs in Node.js codebases: the function returns immediately while the callbacks run in the background, so callers believe the work is done before it is. Use `for-of` with `await` for serial processing, or `Promise.all` with `.map` for parallel - and be explicit about which concurrency model you want. Unbounded `Promise.all` across 500 records can saturate a database connection pool just as effectively as a bug.
</InProduction>


for, for-of, for-in, forEach - which to use and why forEach can't be awaited.