Week 3 calculator build

Why this matters

Six days ago you could not store a value. Today you assemble the whole week — types, operators, conditions, functions, arrays, and objects — into one program with a real job: a resistor-network calculator that validates its input, reports failures clearly, and remembers what it computed.

The new skill is not syntax. It is decomposition: turning a sentence describing what you want into small functions, each with one responsibility, before writing any of them. Every remaining week leans on it.

Decomposing a requirement

Start from the requirement in plain words:

Given a list of resistor values and a mode (series or parallel), calculate the total resistance, reject invalid input with a clear message, and keep a record of every calculation.

Now find the separate responsibilities. A useful test: each should fit in a sentence with no "and".

Responsibility	Function
Add resistances in series	seriesResistance(values)
Combine resistances in parallel	parallelResistance(values)
Decide whether input is usable	findProblem(values)
Route one request, shape the answer	runCommand(command)
Show a result to a human	the loop at the bottom

Splitting like this isolates responsibilities and lets you reuse logic. When a parallel result looks wrong, exactly one function can be at fault, and you can test it alone with numbers you already know. In one 60-line block the bug could be anywhere.

The calculation functions

Both take an array of values and return a number. Both are pure (Day 18) — no printing, no outside state.

function seriesResistance(values) {
  let total = 0;
  for (const r of values) {
    total += r;
  }
  return total;
}

function parallelResistance(values) {
  let reciprocalSum = 0;
  for (const r of values) {
    reciprocalSum += 1 / r;
  }
  return 1 / reciprocalSum;
}

Series is the sum. Parallel is the reciprocal of the sum of reciprocals — 1/Rt = 1/R1 + 1/R2 … — so the accumulator collects 1 / r and the return inverts it at the end.

Verifying calculations manually

Never trust a formula you have not checked against an answer you produced yourself. Pick values where you already know the result:

• Series 220 + 330 + 470 = 1020 — plain addition.
• Parallel 1000 and 1000 = 500 — equal resistors in parallel halve.
• Parallel 220 and 330 = 132 — check with (220 × 330) / (220 + 330) from Day 18.

Three known answers catches a transposed operator. Do this before adding features.

Handling errors visibly

Invalid input must produce a message naming the rule broken, not a silent wrong number. Use guard clauses from Day 17, and return the problem rather than printing it, letting the caller decide how to show it.

function findProblem(values) {
  if (values.length === 0) return "No resistor values supplied.";
  for (const r of values) {
    if (typeof r !== "number" || Number.isNaN(r)) return `Not a number: ${r}`;
    if (r <= 0) return `Resistance must be positive: ${r}`;
  }
  return null;
}

The convention: return null when there is no problem, a message string when there is. null is deliberate emptiness (Day 15), exactly what "checked, nothing wrong" means. The caller writes if (problem !== null).

Routing and recording

runCommand takes one command object — { mode, values } — validates it, dispatches to the right calculation, and returns a result object with a consistent shape (Day 20).

function runCommand(command) {
  const problem = findProblem(command.values);
  if (problem !== null) {
    return { mode: command.mode, ok: false, message: problem };
  }
  if (command.mode === "series") {
    return { mode: "series", ok: true, ohms: seriesResistance(command.values) };
  }
  if (command.mode === "parallel") {
    return { mode: "parallel", ok: true, ohms: parallelResistance(command.values) };
  }
  return { mode: command.mode, ok: false, message: `Unknown mode: ${command.mode}` };
}

Every path returns an object carrying ok, a boolean saying whether it worked, so the caller never guesses whether ohms is meaningful. Note the final return: an unrecognised mode is a failure with a message, not a crash and not a silent undefined.

Because each result is an object, pushing them into an array (Days 19 and 20) gives you a history in memory for free.

Walkthrough

Create calculator.js with the functions above, then this driver. The command array simulates a menu: each entry is one thing a user asked for.

const menu = [
  { mode: "series", values: [220, 330, 470] },
  { mode: "parallel", values: [1000, 1000] },
  { mode: "parallel", values: [220, 330] },
  { mode: "series", values: [100, -50] },
  { mode: "power", values: [220] },
];

const history = [];

for (const command of menu) {
  const result = runCommand(command);
  history.push(result);
  if (result.ok) {
    console.log(`${result.mode}: ${result.ohms.toFixed(2)} ohms`);
  } else {
    console.log(`${result.mode}: ERROR - ${result.message}`);
  }
}

let failed = 0;
for (const r of history) {
  if (!r.ok) failed++;
}
console.log(`Ran ${history.length} operations, ${failed} failed.`);

Run node calculator.js:

series: 1020.00 ohms
parallel: 500.00 ohms
parallel: 132.00 ohms
series: ERROR - Resistance must be positive: -50
power: ERROR - Unknown mode: power
Ran 5 operations, 2 failed.

Five commands, five outcomes: three verified numbers and two failures that each name what is wrong. !r.ok uses the NOT operator from Day 17.

Your turn

Deliverable: a working calculator plus five manually verified test cases.

1. In js-basics/, create calculator.js. Write your responsibility table as a comment block before writing any function.
2. Implement seriesResistance and parallelResistance yourself. No printing inside either.
3. Verify them against the three known answers above. Do not continue until all three match.
4. Implement findProblem with guards for empty list, non-number, and zero or negative. Each gets its own message.
5. Implement runCommand returning { mode, ok, ... } for every path, including an unknown mode.
6. Build a menu array of five commands including at least two failures, loop over it, push each result into history, and print a success or error line per command.
7. Add a summary using history.length, plus one line per past calculation replayed from history — proving the record is real and not just the last value.
8. Write your five test cases as comments: input, your hand-worked answer, the printed answer.

Common pitfalls

• Writing it all in one block, then splitting. Decompose first; extracting functions from working spaghetti is much harder than starting with the boundaries.
• Printing inside calculation functions. Return values, print in the loop. Otherwise you cannot reuse or test them.
• Skipping the known-answer check. A program only ever run on unverifiable values has not been tested.
• Losing failures. If only successes go into history, the record lies. Push every result and let ok carry the outcome.

Verify it yourself

Open today's reference, MDN's Dynamic scripting with JavaScript, and revisit its pages on functions and objects with a finished program in front of you.

1. Find MDN's guidance on when to break code into functions. Does it match the "one sentence without and" test used here?
2. This calculator returns error strings. MDN documents throw and try...catch as an alternative. Note one difference in how a caller handles each. You will use them on Day 24.

Write both answers as comments at the bottom of calculator.js.