switch, and when to avoid it

Some decisions are not a ladder of different questions. They are the same question asked once, with a list of possible answers: which month is this, which status code came back, which button was pressed. Writing that as 'else if (month === "january") ... else if (month === "february")' works, but you end up repeating the variable name and the === on every single line, and the one thing that actually varies gets lost in the noise.

A switch is the shape for that case. Picture an old telephone switchboard: one incoming call, a panel of labelled sockets, and the operator plugs it into the socket whose label matches. You state the value once at the top, then list the labels.

You write 'switch (value) {' and then, inside the braces, a series of 'case someLabel:' lines. When the switch runs, JavaScript compares the value against each case label in turn and jumps to the first one that matches. The statements after that label run - and they are not wrapped in braces of their own, which is unusual and is the source of the surprise in the next section.

'break;' ends the switch and continues after its closing brace. 'default:' is the label for 'nothing matched', and it plays the same role as the final else in a chain: without it, an unmatched value simply does nothing at all, silently. Put default last, where a reader expects to find it, and write it even when you believe every case is covered.

Inside a function you will often see 'return' used instead of 'break'. That works because returning leaves the function entirely, so it ends the switch as a side effect. Whichever you use, be consistent within one switch.

Matching a case is done with strict equality - the same === you already know. There is no type conversion. A switch on the text "1" will not match 'case 1:', and a switch on the text "February" will not match 'case "february":' because the capital letter makes it a different value.

This is a good thing: it means a switch never surprises you with a hidden conversion. It also means that when a switch mysteriously falls to its default, the first thing to check is the type and the exact spelling of the value coming in - values arriving from a form or a file are text far more often than beginners expect.

Once a switch has jumped to a matching label it keeps running forward through the following statements, and it does NOT stop at the next case label. It carries on until it meets a break, a return, or the closing brace of the switch. That behaviour is called fall-through, and it is why break exists at all.

Forgetting a break is therefore not a syntax error and not a warning. It is a program that quietly does two things where you meant one, and it usually shows up as a bug report about one specific input rather than as a crash.

The same behaviour is genuinely useful when you stack several labels with nothing between them - 'case "saturday": case "sunday": return "weekend";' - because a match on either label lands you in the same block. That is the deliberate kind. The way to keep them apart when reading code is simple: labels stacked with no statements between them are intentional; a label reached after real statements that lack a break is a bug until proven otherwise.

Case labels look like they create separate compartments. They do not. The braces of the switch form one single block, and every case shares it, so declaring 'let total' in one case and 'let total' in another is declaring the same name twice in the same scope - a SyntaxError, and the program refuses to start.

The fix is to give the case its own braces: 'case "a": { let total = 1; break; }'. Those braces are a block statement of exactly the kind you met in the first lesson, and they give the declaration somewhere private to live. Many teams write every non-trivial case that way as a matter of habit.

A switch can only ask one kind of question: is this value exactly equal to that one? The moment a branch needs a range ('under 5'), a comparison ('longer than the last one'), or two conditions combined with &&, a switch cannot express it. You will see people force it by writing 'switch (true)' and putting real conditions in the case labels; it works, and it is a disguised if / else chain that is harder to read than the real thing. Use the chain.

The other limit is length. Twelve cases that each return a fixed value are really a table of data pretending to be code - and a table belongs in a data structure you can look a value up in, which is what the data-modelling module builds. That is not available to you yet, so a switch is the right answer today; it is worth knowing now that it is not the last word.

The honest summary: reach for a switch when you have one value, several exact matches, and a sensible default. Reach for if / else when the branches ask different questions.

A switch tests one value against exact case labels using ===, jumps to the first match, and keeps running until a break or return. Stacked labels with nothing between them share a body deliberately; a missing break is the same behaviour by accident. default catches everything else and belongs last. All the cases share one block, so a let declaration in a case needs its own braces. When a branch needs a range or a combined condition, use if / else instead.