Session 6: Functions, Data & Loops

A function is a named block of code you can run whenever you want, with inputs and an output. They exist for two reasons: reuse — write the calculation once and call it from five places — and clarity — a function called `formatPrice` says what it does far better than three lines of arithmetic inline.

The structure is parameters in, `return` out. A function that does not return anything returns `undefined`, which is the source of the classic bug where a function correctly computes a value and the caller receives nothing because the `return` was forgotten. Computing is not the same as returning, and the distinction takes everyone by surprise once.

Then the discipline: one function, one job. A function called `processOrder` that validates, calculates, formats and displays is four functions wearing a coat, and it cannot be tested or reused in parts. Name it for what it does — `validateOrder`, `calculateTotal` — and let another function call them in sequence. Small named functions are also self-documenting: reading `calculateTotal(items)` tells you more than reading the arithmetic.

A variable declared inside a function exists only inside it, which is what you want: a function that does not touch anything outside itself is predictable and testable. A function can read variables from outside — but if it depends on them, it becomes hard to reason about, because its behaviour now depends on state elsewhere. Prefer passing values in as parameters and getting results back via `return`.

Then arrow functions, the shorter syntax: `const double = (n) => n * 2;`. They are exactly equivalent for most purposes and are the modern idiom, particularly for short callbacks. The difference that occasionally matters is that arrow functions do not have their own `this`, which affects them inside object methods — worth knowing about, rarely worth worrying about at this stage.

The practical rule: use whichever is clear. Arrow syntax for short one-expression callbacks, function declarations for anything with a body and a name you will call from several places. Consistency within a file matters more than the choice itself.

An array is an ordered list, written `[1, 2, 3]`, and its positions start at zero — the first item is at index 0, which is the single most important thing to internalise about arrays. Access with `items[0]`, get the length with `items.length`, add with `push`, and check whether something is in there with `includes`.

An object is a collection of named values: `{ name: 'Ada', price: 4500 }`. Access with `obj.name` or `obj['name']`. Objects are how you represent a thing — a product, a user, an order — and arrays of objects are how you represent a list of things, which is the shape of almost all real data: `[{ name: 'Ada', price: 4500 }, { name: 'Bisi', price: 3200 }]`.

Then the two things that bite. Index out of range returns `undefined` rather than an error, so `items[10]` on a five-item array silently gives you nothing and the error appears later somewhere else. And accessing a property of `undefined` throws — `user.address.city` fails entirely if `address` is missing, which is why the optional chaining operator `user?.address?.city` exists, returning `undefined` instead of crashing.

The modern way to go through an array is a `for...of` loop — `for (const item of items) { … }` — which gives you each value in turn and cannot go out of range. It is the right default for anything where you simply need each item.

The classic indexed loop — `for (let i = 0; i < items.length; i++)` — is what you need when you require the position as well as the value, and it is where the off-by-one error lives. The condition must be `i < items.length`, not `i <= items.length`; the latter runs one extra time with `i` equal to the length, which is one past the last index, producing `undefined`. This is the most common loop bug there is and it is worth memorising the correct form.

Then the array methods, which replace most hand-written loops and read far better. `map` produces a new array by transforming each item — `items.map(i => i.price)`. `filter` produces a new array of the items passing a test — `items.filter(i => i.inStock)`. `find` returns the first match. `reduce` combines everything into one value, such as a total. Chaining `items.filter(inStock).map(getPrice).reduce(add)` expresses an entire data operation in one readable line, and it is the idiom you will see in every real codebase.

An event is something the user did — a click, a keystroke, a form submission — and JavaScript can respond to it. The pattern is `element.addEventListener('click', handler)`, where the handler is a function that runs when the event happens. Note that you pass the function without calling it: `handleClick`, not `handleClick()`, because the parentheses run it immediately rather than handing it over to be run later.

Then the two behaviours that need managing. `event.preventDefault()` stops the browser's default action, which is essential on a form: without it, submitting reloads the page and your JavaScript result vanishes. And event delegation — attaching one listener to a parent rather than one to each child — which is how you handle a list of items, including ones added later, without re-attaching listeners every time.

The handler receives an event object describing what happened, including `event.target`, the element that was actually clicked. That is what makes delegation work: one listener on the list, and `event.target` tells you which item was involved. This pattern is the foundation of nearly all interactive interfaces.