JavaScript: Basic, 81–120

Division is where naira-with-decimals finally breaks. ₦12,500 over three people is ₦4,166.666…, and every way of rounding that to a printable amount is wrong: round each share up and you collect ₦12,500.01, round down and you are a kobo short. The money has to go somewhere, so decide where — here the first extra people pay one kobo more, which is what a POS receipt does.

toFixed being a string is the second trap, and it hides the first: '4166.67' looks like a number, so it gets multiplied back later and the penny reappears as 12500.01. Keep integers in kobo all the way through, divide with Math.floor and a remainder, and make "the parts sum to the whole" an assertion rather than a hope.

The three Object functions cover almost everything a beginner needs from an object: keys to list, values to total, entries to do both at once. All three return arrays, so every array method is available afterwards — Object.values(fares).reduce(...) replaces the loop above entirely.

fares.length being undefined catches people out because it does not throw; it silently means "no such key". And key order is insertion order except for keys that look like array indices, which are always visited in ascending numeric order. If you need dependable ordering across mixed keys, or keys that are not strings, use a Map.

Dot notation is the readable default and cannot do three things: use a name held in a variable, use a name that is not a valid identifier ('seat number'), or use a name built at runtime. Brackets do all three, which is why lookup tables and loops over Object.keys are written with them.

passenger.field returning undefined rather than throwing is the trap: the dot took field as a literal key name, found none, and said nothing. And keys are always strings — seats[3] and seats['3'] are one property, and two different objects used as keys both stringify to "[object Object]" and overwrite each other. When you need object identity in a key, that is what Map is for.

Three questions get confused with each other. "Is there a key?" is in or Object.hasOwn. "Is the value something?" is !== undefined. "Is the value truthy?" is if (obj.fare) — and that last one is false for 0, '' and false, all of which are real values a fare, a note or a flag might legitimately hold.

'toString' in trip being true is why in is the wrong tool for checking user data: every object inherits a handful of properties, so a lookup keyed on an untrusted string can report a hit that was never written. Object.hasOwn(obj, key) is the modern one-liner for own properties; before it existed the incantation was Object.prototype.hasOwnProperty.call(obj, key), written that way because an object can have its own key called hasOwnProperty.

delete is about keys, and an array index is a key, which is why delete seats[1] is legal and almost never what you want. It leaves a hole: length stays 3, 1 in seats is false, and seats[1] reads as undefined without any key being there. map and forEach skip holes, JSON.stringify writes them as null, and the two behaviours together produce bugs that are miserable to trace. Use splice, or filter for a copy.

Two smaller notes. delete returns true for a key that was never there, so its return value tells you nothing about whether anything was removed — check with Object.hasOwn first if you care. And setting a key to undefined is not removal: the key survives, Object.keys still lists it, and JSON.stringify then drops it, so the two spellings differ in what reaches your server.

Spread reads left to right and the last write wins, so defaults go first and the caller's object last. Reversing that is a common and quiet bug: every value the caller passed is silently replaced by a default, and nothing throws. Object.assign(target, source) does the same job but mutates target — fine when you built the target yourself two lines earlier, dangerous when the target is something you were handed. Object.assign({}, a, b) is the safe spelling.

"Shallow" is the trap worth remembering: base.route and copy.route are one object, so editing the copy changed the original. Only the top level is duplicated. A nested merge needs structuredClone or a deliberate deep merge (exercise 40). And tier: undefined overwriting the default catches people building option objects from optional inputs — filter those keys out first, or use ?? at the point of use.

An if-chain grows a branch per case and has to be read top to bottom; a table is data, so adding epe is one line and the code that reads it never changes. It is also a single lookup rather than up to n comparisons, though at four routes that difference is theatre — readability is the real argument.

The leak is the price. FARES['toString'] finds the inherited function, so ?? null never fires and the caller gets something bizarre back; with an untrusted key, constructor and __proto__ are worse. Guard with Object.hasOwn, or build the table with new Map(...), or Object.create(null) for an object with no prototype at all. Object.freeze(FARES) is worth adding too once the table is settled, so nothing edits your fares at runtime.

Inverting is three lines, and the interesting part is what it destroys. Object keys are unique, so any value appearing twice collapses to one entry and the earlier plate vanishes with no error. The double inversion assertion shows the damage: LSD-114-AB is simply gone.

(out[value] ??= []).push(key) is the fix and the idiom worth learning — logical assignment creates the array only when the key is missing, then the expression evaluates to the array so push follows on the same line. The other quiet conversion is that values become keys, and keys are strings: invert a table of numbers and 20000 comes back as '20000'. A one-to-one table can be inverted; a many-to-one table has to be grouped, and you should know which one you have before you write the loop.

Only undefined triggers a default. fare(4, null) passes null straight through, 4 * null is 0, and the answer is a fare of nothing with no error anywhere — the single most common surprise with defaults, and the reason ?? exists (exercise 98).

Defaults are evaluated left to right at call time, which buys two things. A later default can be computed from an earlier parameter, as surcharge is here. And a default of [] or {} is built afresh on every call, unlike Python, where a mutable default is created once and remembered — a whole class of bug that JavaScript simply does not have. Note also that fare.length is 1: length stops counting at the first default, so it is not a reliable arity.

...rest in a parameter list gathers; ... at a call site spreads. Same three dots, opposite directions, and the pair replaces every use of arguments: rest is a genuine array, so reduce, map and filter are all available, and it can sit after named parameters as in receipt.

arguments is array-like — indices and a length, nothing else — so arguments.map(...) throws a TypeError rather than doing anything useful. It also does not exist inside an arrow function, which inherits it from the enclosing function along with this. The one thing to watch is length: it counts named parameters only, so total.length is 0 despite total accepting anything you throw at it.

Both functions implement the same four rules and the assertion proves it, so the choice is purely about reading. The nested version buries the one interesting line under four ifs and pairs every condition with an else a screen away; the guards read as a list of rules, each with its answer beside it, and the success case sits at the bottom unindented.

Order matters and is part of the design: !account has to come before !account.active, or the second guard throws on null. That ordering is visible in the guard version and hidden in the nested one. The reward is that adding a fifth rule is one line rather than another layer, and it is why { ok, why } is worth returning instead of a bare false — the caller gets to say which rule failed.

[10, 9, 1].sort() giving [1, 10, 9] is the one to memorise: with no comparator, sort converts every element to a string and compares those, so '10' < '9'. Numbers always need (a, b) => a - b.

The deeper habit is knowing which functions change what you handed them. sort, reverse, splice, push, fill all mutate; map, filter, concat, slice return something new. sort is the nastiest because it also returns the array, so const sorted = marks.sort(...) reads like a copy and is not — marks is sorted too, and any code depending on the original order is now broken. Copy first with slice() or [...marks], or use the newer toSorted. A mutating function is not wrong, but it should be obvious from its name, as raiseInPlace is.

this in a plain function is decided by the call, not by where the function was written: trip.labels() sets it to trip, and the bare detached() sets it to undefined, which is why reading this.stops throws a TypeError. The old var self = this dance existed entirely to smuggle the outer this past that rule.

An arrow has no this of its own, so it reads the enclosing scope's — permanently. That makes it right for callbacks inside a method, as in labels, and wrong for the method itself: an arrow written directly in an object literal captures whatever this was outside the object, which is never the object. reader.call({...}) being ignored is the proof that call, apply and bind have no purchase on an arrow. Arrows also have no arguments, no prototype, and cannot be called with new.

Taking the formatting as an argument is the whole idea behind map, filter, sort and every event handler: the walker owns the loop, the caller owns the decision. Two outputs, one walker, no duplication.

['10','10','10'].map(parseInt) giving [10, NaN, 2] is the classic demonstration of the trap: map passes three arguments, parseInt accepts two, so the index arrives as the radix. Index 0 means "guess", index 1 is not a legal radix, and index 2 reads the digits as binary. Passing a function by name is only safe when its extra parameters cannot hurt you — hence map(Number) is fine and map(parseInt) is not. And note the missing brackets matter in both directions: map(shout) passes the function, map(shout()) calls it immediately with no argument and hands map the result.

count outlives makeCounter because the returned functions still refer to it — that is a closure, and it is the plainest way to have private state in JavaScript. gate.count is undefined not because it is hidden but because it is not a property of anything; there is no path to it except through tick and value. Each call to the maker creates a new one, which is why the two counters cannot interfere.

var giving [3, 3, 3] is the interview question and a real bug in any loop that registers handlers. There is one i for the whole function, all three arrows close over it, and by the time they run the loop has finished and left it at 3. let creates a fresh binding per iteration, so each arrow captures its own. Before let, the fix was an immediately-invoked function per turn to make a new scope by hand — the same trick nextTicket uses here, for the same reason.

The ternary earns its place when both branches produce a value for the same slot — assigning one of two fares, choosing a word inside a template. Where the branches do two different things, an if says so more clearly, and where there are four bands rather than three, a lookup table (exercise 87) or a switch (exercise 97) is easier to extend.

'fare: ' + paid ? 'yes' : 'no' is the trap, and it is silent: + runs first, so the condition is the non-empty string 'fare: false', every non-empty string is truthy, and the result is 'yes' regardless of what paid holds. Nothing throws, and a test that only checks the happy path passes. Put brackets round a ternary whenever it shares an expression with anything else.

Fallthrough is a feature and a hazard in the same mechanism. Stacking case 'luxury': case 'executive': with nothing between them is the clean way to give two values one answer. Forgetting a break gives you leaky, where every tier returns ₦200 because control ran through every remaining case — and the compiler is happy, because that is exactly what switch is defined to do.

Returning from each case, as fareBand does, makes the whole class of bug impossible and is the shape to prefer. Two smaller points: switch matches with ===, so a form field's '1' will never hit case 1 — convert first; and default is chosen only when nothing else matched, no matter where it appears, though writing it last is a kindness to the reader. For anything that is purely value-to-value, a lookup table (exercise 87) is shorter than either.

|| asks "is this falsy?", and 0, '' and false are all falsy while being perfectly good answers. A shuttle with 0 seats becomes 14, an empty note becomes 'none', and a customer who turned the air conditioning off gets it back on. ?? asks the narrower question — "is this null or undefined?" — which is almost always the question you meant when filling in a default.

|| is still right when any falsy value should be treated as absent, such as a search box whose empty string means "no filter". ??= is the assignment form and is handy for filling gaps in an options object in place. The syntax error is deliberate on the language's part: a ?? b || c has no obvious precedence, so instead of guessing, the parser refuses and makes you write the brackets.

?. answers one question: is the thing on its left null or undefined? If so, the whole expression stops there and evaluates to undefined, which is why empty.passenger?.contact.phone does not throw even though .phone is unguarded — evaluation never reached it.

partial is the case that catches people. passenger exists, so the chain does not short-circuit; contact is undefined; and the unguarded .phone throws. A ?. guards the step it is written on, so every step that might be missing needs its own. Two limits worth knowing: ?. cannot be used on the left of an assignment, and it says nothing about a key existing — a genuine undefined value and a missing branch read identically, which is what Object.hasOwn (exercise 84) is for. Reach for ?? 'default' at the end rather than leaving undefined to travel further.

Also exercise 34, there asking what type a value is; here the angle is what == does when the two types differ. It converts, following a table nobody remembers, and the results include '' == 0 and [] == false both being true — the array becomes '', which becomes 0, which equals false's 0. Use === and convert deliberately, and these stop being trivia.

The two exceptions worth keeping in your head. null == undefined is true, and both are false against everything else, which makes value == null a genuinely useful one-line "is it missing?" — the same question ?? asks. And NaN === NaN is false, so indexOf(NaN) never finds it and x === NaN is always false; Number.isNaN is the only reliable test, which is why the assertions in this course check Number.isNaN(x) against true rather than comparing to NaN. typeof null being 'object' is the oldest wart in the language and can never be fixed without breaking pages that depend on it.

All three read the same character in the middle of a string and disagree completely at the edges, which is where bugs live. charAt off the end gives '', so stop.charAt(9).toUpperCase() quietly returns '' and the fault surfaces somewhere else; brackets and at give undefined, so the same line throws immediately. The loud failure is usually the kinder one.

stop[-1] is not an error and not the last character — it reads a property named "-1" that does not exist, so undefined. Only at understands negatives, which is the whole reason it was added. Also exercise 5, which rotated a string with slice; here the angle is a single position rather than a whole cut.

Reach for slice and forget substring exists. They agree on the ordinary case, so the difference only shows up when the arguments are computed and one of them comes out wrong: slice(start, end) with end before start returns '', which is visibly empty, while substring silently reorders them and hands back text from a range you never asked for. That is a bug that survives review.

The negative case is the same story. slice(-5) means "the last five", which is the idiom for a suffix; substring(-5) treats -5 as 0 and returns the whole string, so a clamped-to-zero index looks like success. The last assertion is the property worth remembering: because the end is excluded, slice(0, n) and slice(n) partition a string with nothing lost or duplicated.

Also exercise 1, where padStart put a leading zero on a clock's minutes; here the angle is the width rule itself. The argument is the finished length, so padStart(6, '0') on three digits adds three zeros and on eight digits adds none — and adds none silently. If your columns must not exceed a width, pad and then slice, because padding alone will never shorten anything (exercise 37 does the cutting half).

Two smaller edges. A pad longer than one character is repeated and then chopped mid-pattern, so 'ab' gives ababa rather than a whole number of copies. And these live on String.prototype: 87 .padStart is undefined, so calling it is a TypeError. Wrap the number in String(...) before you pad it.

The last assertion is the one that reaches production. ' ' is a non-empty string, so if (value) is true and a required field made entirely of spaces sails through. Trim first, then ask (exercise 116 builds that check properly).

trim is generous about what whitespace means — spaces, tabs, newlines, and the non-breaking space that arrives whenever text is pasted from a web page, which is invisible and not equal to ' '. It is not generous enough for a zero-width space, which is a formatting character rather than whitespace, so 'Yaba\u200b' trims to itself and compares unequal to 'Yaba' for reasons nobody can see on screen. When a string looks right but will not match, print its length. And trim only works on the ends: collapsing runs inside the text needs replace(/\s+/g, ' ').

split(' ') is the trap: it splits on exactly one space, so 'Bola Ahmed' becomes three parts with an empty string in the middle, and the surname ends up being ''. split(/\s+/) treats any run of whitespace as one separator and handles the tab a paste brings with it. The trim matters too — a leading space would still produce an empty first element even with the regex.

The design point is bigger than the code. "First, middle, last" is a Western convention, not a fact: many people have one name, many surnames come first, and plenty contain spaces (de Souza, Ade Bello). This function will get those wrong, and no clever splitting fixes it. If the name matters, ask for the parts you need in separate fields and store what you were given; parse only when you have no choice, as here.

filter(Boolean) is doing real work. Without it a leading space produces an empty word, w[0] on it is undefined, and undefined.toUpperCase() throws — so the crash appears only for input with a stray space, which is exactly the input a user provides. Trimming and filtering together make the empty case return '' instead of a lone separator.

The hyphen is the interesting part, and it is a product question rather than a coding one. Splitting on whitespace gives Ngozi Ade-Bello two initials; splitting on whitespace or hyphens gives three. Both are defensible; what is not defensible is discovering which one you chose from a bug report. Passing the pattern in makes the choice a visible argument. Same ground as exercise 24, which capitalised every word — there the first letter was changed in place, here it is all that survives.

slice(-keep).padStart(text.length, char) is the whole trick: take the tail you want to show, then pad it back out to the original width. That keeps the mask the same length as the number, so a table of masked numbers stays aligned and nobody learns how long the value was from the column shifting.

keep = 0 is the trap, and it is -0. Negative zero equals zero, so slice(-0) is slice(0) — the entire string, printed in the clear, in the one case where you asked for maximum secrecy. The guard turns that into all stars. Masking is presentation, not protection: the full value is still in memory and in the response that carried it, so if it must not reach the browser, mask it on the server. Money and identifiers are also why String(value) is there — a phone number held as a number has already lost its leading zero.

Two is right for "how many times can I take this out", three is right for "how many places does it appear". The split version answers the first because split consumes each match; the loop answers whichever you choose by how far it advances — at + 1 allows overlaps, at + needle.length forbids them. Neither is the correct answer in general, so pick deliberately and say which in the name.

The empty needle is not a hypothetical. indexOf('', from) matches at every position, so a loop advancing by needle.length never moves and hangs the tab; and split('') returns every character, so the split version reports the string's length as an occurrence count. Guarding at the top gives one honest answer to a meaningless question. Also exercise 25, which tallied every character at once; here a single needle is counted, and the overlap question only exists because it can be more than one character long.

replace with a string argument replaces one occurrence, which is the single most common cause of "it worked on my test data". replaceAll exists to say what you meant; before it, the only way was a global regex, and forgetting the g gave the same one-match behaviour silently. replaceAll refuses a non-global regex outright rather than repeating that mistake — a rare case of the language choosing a loud error over a plausible guess.

The $ rules bite when the replacement is data rather than a literal. Any user-supplied text containing $&, $1 or $' will be interpreted, so pasting a price of $5 into a replacement string is a real bug. Pass a function instead: its return value is inserted verbatim, no escaping and no surprises. And note none of this mutates — replace returns new text, so ignoring the return value is a no-op.

toLowerCase() before splitting is the line people leave out, and it only shows up on real input: a header of TOTAL FARE or a label of Bus Stop keeps letters that should have been flattened, so naiveCamel yields TOTALFARE and BusStop — neither of which matches the key you later look up. Lowercase first, then raise exactly the letters you intend to raise.

Treating spaces, underscores and hyphens as one class of separator means the same function converts a form label, a database column and a CSS class, which is where these conversions are actually used. The round trip is not quite lossless in general: kebab splits on every capital, so parseHTTPResponse becomes parse-h-t-t-p-response. Acronyms need a smarter pattern or a policy of not using them. Also exercise 24, which capitalised the first letter of each word for display; the difference here is that the spaces are removed, so the result is an identifier rather than a title.

"Reverse a string" is three questions wearing one name, and the assertions separate them: word order, letters within each word, and every character in the line. Getting asked for one and delivering another is the usual interview failure.

reverse() mutates. line.split(' ').reverse() is safe because split just made the array, but existingArray.reverse() rearranges the caller's data, which is a bug at a distance — [...existing].reverse() costs one spread and removes the class of problem. The last two assertions are the character-width trap: split('') cuts on UTF-16 units, so a bus emoji becomes two broken halves and reversing them produces a replacement glyph, while [...text] iterates code points and keeps it intact. Also exercise 14, which reversed text to test for a palindrome; here the angle is what "reversed" means when the unit is a word or a character wider than one unit.

These three replaced a generation of indexOf comparisons, and the win is that startsWith('080') cannot be typed wrong while indexOf('080') === 0 can: > 0, !== -1 and === 0 mean three different things and look alike at a glance.

The position arguments are the part people miss. startsWith(needle, i) asks whether the needle appears at i, which is a cheap way to test a fixed field inside a formatted string without slicing it out first, and endsWith(needle, i) pretends the string ends at i. Passing a regex throws a TypeError rather than stringifying it, so startsWith(/^080/) fails immediately instead of silently comparing against "/^080/" — for a pattern you want test (exercise 114 does the phone properly). And every string includes '', which matters when the needle comes from an empty search box: the filter matches everything, which is usually what you want, but by accident rather than design.

Also exercise 1, which formatted a clock time from a Date; here the input is an elapsed duration, and that difference is the whole exercise. A duration has no midnight to wrap at, so the new Date(secs * 1000).toISOString().slice(11, 19) trick that circulates as the elegant answer reports a 24-hour shift as 00:00:00 and a 25-hour one as 01:00:00. Divide and take remainders instead; then 100 hours prints as 100:00:00, because padStart(2, '0') pads short values and leaves long ones alone (exercise 103).

Math.floor on the absolute value, with the sign put back in front, is what keeps -90 as -00:01:30; flooring a negative directly rounds towards minus infinity and gives -1 hours and positive minutes, which is nonsense (exercise 52 is the floor against trunc version of this). Flooring also means a stopwatch never shows a second it has not finished — 59.9 seconds is 00:00:59, and rounding up would let it display 01:00 before the minute exists.

Normalise then validate. The alternative — one pattern that tolerates spaces, hyphens, brackets, a leading plus, a country code and an optional trunk zero — is unreadable and impossible to extend, and it leaves the caller holding whichever of five formats arrived. Reducing every input to a single canonical form means the regex describes one shape, and everything downstream compares and stores that shape.

The trunk zero is the edge that catches people. +234 803 ... drops the zero and +234 0803 ... keeps it, both are written in the wild, and blindly prepending a zero after stripping 234 gives 00803.... The prefix sniffing is a heuristic, not a parse: a number that genuinely begins with the digits 234 would be mangled, which is the price of guessing. And as with the email in exercise 49, the last assertion is the lesson — 08000000000 is perfectly formed and belongs to nobody. Only a one-time code sent to the line proves it exists.

The KJ0 case is the one worth remembering. A zero in a letter slot fails the pattern, which is correct, but the person who typed it cannot see the difference between 0 and O in most fonts — so "invalid plate number" is a useless message. Either say which slot is wrong, or fix the obvious confusions before validating (O to 0 in digit slots and back in letter slots) and tell the user what you assumed.

Stripping non-alphanumerics before matching means one pattern covers every way a human might type separators, and it makes the validator and the formatter share a single definition — worth doing because the two drifting apart is how a value passes validation and then displays wrongly. Returning '' rather than a half-formatted string for invalid input keeps the failure visible. As in exercise 114, shape is all this proves: AAA-111-AA is well formed and hanging on no vehicle.

if (!value) return 'required' is the bug this exercise exists to kill. It rejects 0, which is a valid number of extra bags; it rejects false, which is a customer deliberately declining air conditioning; and it accepts ' ', which is nothing at all. The falsy set and the empty set are different sets — exercise 98 makes the same point about || against ??.

So the check is per type: nullish is missing, a string is measured after trimming (exercise 104), a number must be finite so NaN from a failed Number() and Infinity from a division both fail, and anything else counts as given. The last assertion is deliberately uncomfortable: [] is a value, so this says provided, while a multi-select that submitted an empty array chose nothing. There is no universal answer to "is this filled in" — there is only the answer for this field, which is why the rule belongs next to the field rather than in one clever helper.

Also exercise 37, which cut text to a length; here the angle is what a length counts. JavaScript strings are UTF-16, and .length reports storage units, not characters — so an emoji costs 2, and a note of ten bus emojis reports 20 and is rejected by a 20-character limit the user has not reached. Spreading or Array.from iterates code points and gives the count a person would recognise.

Code points are closer, not correct. A flag, a family emoji or an accented letter written as e plus a combining mark is several code points and one visible character, so [...'e\u0301'].length is 2. The genuinely correct unit is the grapheme cluster, which needs Intl.Segmenter; reach for it when the count is shown to a user, as in a character countdown. Note also that the inclusive bounds are asserted at all four edges — min, min - 1, max, max + 1 — because an off-by-one in a range check passes every test that only uses values in the middle.

Number('') being 0 is the trap that costs money. An empty quantity field converts to zero, zero passes a "must be a number" check, and the order is placed for nothing — or, with a range of 0 to 20, accepted outright. Test for empty text before converting, which is also why trim comes first: Number(' ') is 0 as well.

Number against parseInt is the other decision. parseInt reads as far as it understands and discards the rest, so '12kg' is 12 and '1e2' is 1; Number demands the whole string be numeric, so '12kg' is NaN and '1e2' is 100. For validating user input, whole-string strictness is what you want — silent truncation turns a typo into a plausible order. Number.isFinite rather than the global isFinite avoids the same coercion coming back in through the check itself, and returning a reason instead of a boolean is what lets the form point at the field and say why.

The object trap is the reason this is not just includes. AS_OBJECT[value] looks like a fast membership test until value is 'toString', 'constructor' or '__proto__' — all inherited from Object.prototype, all truthy, none of them yours. With user input as the key that is a validation bypass, not a curiosity. Use includes, a Set, or Object.hasOwn (exercise 84), or build the lookup with Object.create(null) so there is no prototype to inherit from.

includes over indexOf for the same reason as exercise 112: an index comparison has three plausible spellings and only one is right. It also uses SameValueZero, so it finds NaN, which indexOf cannot because indexOf compares with === and NaN === NaN is false (exercise 100). Normalising the input before the comparison — trim, lowercase — is what turns a strict list into one a human can type into, and keeping the list in one const means the same array can populate the <select> that offered the choice.

The gap between 69.5 and 75 is the exercise. Averaging the three scores treats a coursework mark as equal to an exam that is half the grade, and here that difference is a whole letter — the student who did well on assignments and badly in the exam gets an A from the wrong formula. Weight, then divide by the total weight.

Dividing by the total rather than by 100 is what makes the function reusable: 20/30/50, 0.2/0.3/0.5 and 1/3/5 all give 69.5, and a component that gets dropped reweights the rest automatically instead of quietly scoring the missing part as zero. The totalWeight === 0 guard matters because 0 / 0 is NaN, and NaN propagates silently through every later sum and comparison — the assertion pins that down rather than trusting it. The letter ladder must descend: written from the lowest threshold up, every passing mark would return the lowest letter, because the first true branch wins (exercise 91 on guard clauses is the same shape).