2.3 The switch Statement

Step 1 — Identify the shape of each chain: A switch fits when one value is compared against a list of exact values with ===.

Step 2 — Check option a: score > 90 and score > 80 are range comparisons, not equality against fixed values. There is no finite list of numbers to match, so this cannot be a switch.

Step 3 — Check option b: color === "red" and color === "green" compare the same variable to exact string values. This is exactly the shape switch was designed for.

Step 4 — Check option c: The conditions involve two variables (age and hasID) and &&. That is not one value compared against a list, so it cannot be a switch.

Answer: b. Only the chain comparing color to exact values can be rewritten as a switch.

Step 1 — Evaluate the switch value: grade is "B".

Step 2 — Compare cases in order: case "A" fails because "B" === "A" is false. case "B" matches because "B" === "B" is true.

Step 3 — Run the matched case and stop: console.log("Good") runs, then break ends the switch immediately. Because of the break, default never runs — it only executes when no case matched.

Answer: It prints Good.

Step 1 — Recall how default works: JavaScript checks every case label in order; if none matches, execution jumps to the default: clause wherever it appears in the block. Position does not matter for whether it runs.

Step 2 — Note the convention: Putting default in the middle is legal but confusing to readers, so the convention is to write it last. If a mid-block default has no break, fall-through can also make following cases run unexpectedly after it.

Answer: Yes — default still runs when no case matches, regardless of where it is written. Its position affects readability (and possible fall-through), not whether it executes.

Step 1 — Match the value: x is 1, so case 1 matches and prints one.

Step 2 — Fall through: case 1 has no break, so execution continues into case 2 without checking its value and prints two.

Step 3 — Stop at the break: case 2 has a break, so the switch ends there. case 3 is never reached.

Answer:

one
two

Step 1 — Why it is harmless: A missing break on the last case causes fall-through into whatever comes next — but below the last case there are no more cases, only the end of the switch block. Execution leaves the switch anyway, so nothing extra runs.

Step 2 — Why programmers write it anyway: If someone later adds a new case below the old last case, the missing break would suddenly create an accidental fall-through bug that silently changes behavior. Writing the final break makes the code safe under future edits.

Answer: It is harmless because there is nothing below the last case to fall into; many programmers include the break anyway so that adding cases later cannot introduce a silent fall-through bug.

Step 1 — Trace the matching: n is the number 0. switch uses strict comparison (===). A number is never strictly equal to a boolean, so 0 === false is false and case false fails.

Step 2 — Continue down the cases: case 0 matches because 0 === 0 is true, so it prints matched zero and the break ends the switch.

Step 3 — Explain the common confusion: Although 0 is falsy (an if (n) would treat it as false), switch does not test truthiness — it tests strict equality against each case value.

Answer: It prints matched zero. case false does not match because strict equality requires the same type, and the number 0 is not equal to the boolean false.

Step 1 — Diagnose the problem: age is the string "18", and case 18: holds the number 18. Strict comparison means "18" === 18 is false, so the case can never match unless we convert the type.

Step 2 — Convert at the switch header: Wrapping the switched value in Number() converts the string to the number 18 before any case is checked:

▶ Press Run to see the output…

Output:

Adult

Answer: Use switch (Number(age)) { ... } — converting the value to a number lets case 18: match strictly, without changing the case itself.

Step 1 — Examine the problem shape: One variable (priority) is compared against a short, fixed list of exact string values: "low", "medium", "high".

Step 2 — Match shape to tool: A switch exists precisely for "one value, a list of exact possibilities." There are no ranges, no second variable, and no compound conditions.

Answer: A switch fits best, because one value is being compared against a fixed list of exact values — exactly the structure switch was designed for.

Step 1 — Set up the switch on code: Each status code gets its own case, with default handling anything unrecognized.

▶ Press Run to see the output…

Output:

Not Found

Answer: The switch above prints OK for 200, Not Found for 404, Server Error for 500, and Unknown status for anything else.

Step 1 — Group the weekend days: Stack case "Saturday": and case "Sunday": with no code between them so both fall into the same block.

Step 2 — List all five weekdays explicitly: Since the instructions forbid using default for weekdays, each weekday needs its own stacked case label falling into the Weekday print.

▶ Press Run to see the output…

Output:

Weekend

Answer: The switch above groups Saturday and Sunday into one block printing Weekend, and groups Monday–Friday into another block printing Weekday, naming all seven days explicitly.

Step 1 — Trace the bug: size is "small", so case "small" matches and prints Small: $2. But that case has no break, so execution falls through into case "medium" and prints Medium: $3, then into case "large" and prints Large: $4 before hitting that case's break. Three lines instead of one.

Step 2 — Fix by adding breaks: Add a break after each case's output so each match stops immediately.

▶ Press Run to see the output…

Output:

Small: $2

Answer: Add break; after the case "small" body (and after case "medium" for safety). Now only Small: $2 prints.

Step 1 — Where text-input values come from: Values read from a text input arrive as strings — even if the user types digits, the program receives something like "3", not the number 3.

Step 2 — Apply strict comparison: A switch compares with ===, which requires both the same value and the same type. Since the string "3" is never strictly equal to the number 3, case 3: fails every time.

Step 3 — Conclude: No string can ever strictly equal a number, so case 3: is dead code — it looks reasonable but can never run unless the value is converted first (for example with Number(...)).

Answer: Text inputs always produce strings, and switch compares strictly, so a string like "3" can never match the number in case 3: — the case is unreachable dead code.

Step 1 — Convert each case to an equality test: Each case X: becomes if/else if (command === X), and default becomes the final else.

▶ Press Run to see the output…

Output:

You walk north.

Answer: The if...else chain above behaves identically to the original switch: it tests command against "north", then "south", and falls back to the final else for anything else.

Step 1 — Look at what the conditions test: The chain uses score >= 90, score >= 80, score >= 70 — these are range comparisons, not comparisons against exact values.

Step 2 — Ask the key question: A switch requires the whole test to be expressible as a finite list of exact values to match one switched value against. Here there is no such list: infinitely many scores satisfy score >= 80, and the boundaries (90, 80, 70) are thresholds, not specific values to match.

Step 3 — Conclude: Forcing this into a switch would mean listing every possible score from 0 to 100 as a case — absurd and fragile — or grouping hundreds of cases per grade band, which is worse than the original chain.

Answer: It cannot be rewritten as a switch because the conditions are ranges (>= boundaries), not equality checks against a finite list of exact values — and ranges are exactly what switch cannot express.