Project: building a decision table

You now have every tool this module offers: if / else, truthiness, && and || and ??, switch, and the conditional operator. Real bugs in real code are almost never caused by getting one of those wrong. They are caused by the shape of the decision as a whole.

Three failures cover nearly all of them. A rule that can never be reached, because an earlier, broader rule already claimed its inputs. An input that matches no rule at all, so the function quietly returns undefined. And two rules that both match, where which one wins depends on the order you happened to write them in - which means the behaviour was never decided, only inherited.

None of the three produces an error message. All three are invisible while you test the cases you were thinking about. The defence is not a new piece of syntax; it is doing the thinking in a table before you do it in code.

A decision table is a list of rows. Each row has a condition and the answer to give when that condition holds. You write it in your own words first - on paper, or as comments above the function - and only then translate it, one row per branch, in the same order.

The rules that make it worth doing are simple. Rows are tried from the top, and the first one that matches wins, exactly like an if / else chain. Every row must be reachable: if the rows above it already cover everything it describes, it is dead code. And the last row must be a catch-all with no condition, so that every input leaves with an answer.

The reason to write it before the code is that a table makes those properties visible. Looking down a column of conditions, you can see that 'weight over 30' has to come before 'domestic', and that nothing handles a negative weight. Looking at the same logic already spread across fifteen lines of braces, you cannot.

The first rows of almost every useful table are not about the interesting cases. They are about the inputs that should not exist: a weight that is negative, a value that is not a number at all, a name that was never supplied. Handling them first is called a guard clause, and the payoff is that every row below can assume the input is sane.

That is what keeps the interesting rules readable. If you do not guard first, every later row has to defend itself, and a rule that should read 'domestic and under a kilo' turns into 'a number, and not missing, and above zero, and domestic, and under a kilo'.

Two checks do most of the work. 'typeof value === "number"' asks whether you were given a number at all, since text arriving from a form or a file is the usual culprit. And Number.isNaN(value) asks whether the value is the special not-a-number result you met in module 1 - the thing you get back from a failed conversion. It deserves its own check because NaN is genuinely a number as far as typeof is concerned, and it is not equal to anything, including itself, so a comparison like 'value > 0' is simply false for it rather than being an error.

When two rows could both match the same input, the one you wrote first is the one that happens. That is not an accident of the language to be worked around - it is the mechanism you use to express priority, and the way to use it deliberately is to sort your rows from most specific to most general.

'Express delivery to a domestic address' is more specific than 'a domestic address', so it goes above it. 'Over 30 kilos' is more specific than any destination rule, because no destination can rescue a parcel that is too heavy, so it goes above all of them. Read your table top to bottom and each row should be narrower than the one below.

The check that catches the mistake: for each row, ask what an input would have to look like to reach it. If nothing can - because a broader row above already caught everything it describes - the row is unreachable and one of the two is wrong.

A function that ends without returning gives back undefined. Not an error, not a warning - undefined, quietly, which then travels through the rest of the program until it causes a confusing failure somewhere completely different.

That is why the last row of a table is always a catch-all with no condition. Whether it returns a safe default, or a value like null that plainly means 'no answer for this input', it must return SOMETHING chosen on purpose. Deciding what to do with an input you did not anticipate is part of the design, not an afterthought.

The related habit: when you add a new rule later, re-read the whole table rather than pasting the new row at the bottom. A row appended below the catch-all can never run, and a row that belongs above an existing one changes the answer for inputs you were not thinking about.

Once the table exists, testing stops being guesswork. Take one example input from every row - including every guard row - and check that each produces the row's stated answer. If a row has a boundary in it, such as 'up to 2 kilos', take two examples: one exactly on the boundary and one just past it. That is where errors hide, as the ticket-price exercise showed.

A row you cannot write an example for is unreachable. An example you cannot place in any row means the table is incomplete. Both discoveries are worth far more than the test itself, and you get them before the code exists.

This is the habit the testing module later formalises, and it works today with nothing but a function and a few calls to console.log.

Write the rows before the code: condition on the left, answer on the right. Guards first, then most specific to most general, then a catch-all with no condition so every input has an answer. Check every row is reachable, and take one example from each - two at every boundary - as your test list.