Conditionals and Decisions

COMPLETE LESSON · ABOUT 30 MIN OF ACTIVE PRACTICE

Learn Conditionals and Decisions step by step

Follow the lesson in order: understand the model, trace worked examples, run a controlled experiment, debug a faulty assumption, build independently, and verify your reasoning.

LESSON MAP

What you will understand and apply

Handle invalid input with a guard clause
Test immediately around every threshold
Name complex boolean subconditions
Implement and test a progress classifier whose ranges have no gaps or overlaps.

DEEP EXPLANATION

Build the complete mental model

Build the mental model

if, else if, and else select exactly one branch from an ordered chain. The first truthy condition wins, so order is part of the policy. Begin with examples at each boundary, then translate them into comparisons. A final else should mean something precise, not silently absorb malformed data that should have been rejected. Before writing more syntax, name the values involved in Conditionals and Decisions, who creates them, and which result or effect the program promises. Trace the smallest example by hand and identify any browser or runtime API separately from the language feature. A useful mental model should predict a changed input, not merely describe the demonstration after it runs.

Use the API deliberately

Guard clauses return or throw near the top of a function when preconditions fail. They reduce nesting and keep the normal path visible. Truthiness is useful only when every falsy value means the same thing. If zero, false, or an empty string has a valid domain meaning, compare the accepted cases explicitly instead of using a broad shortcut. During implementation, keep the if rule in a focused function or event boundary with explicit inputs. Choose names that reveal the domain, keep calculation separate from document, console, storage, or network effects, and prefer the narrowest API that expresses the problem. Compare this design with one reasonable alternative and explain why the selected construct makes ownership or control flow clearer.

Handle boundaries and tradeoffs

switch works well when one expression is matched against several exact values; it is less natural for overlapping ranges. The conditional operator is an expression suited to one small two-way value choice, not a compressed replacement for a long policy. Name booleans such as hasPermission or isWithinLimit so tests can describe the rule that failed. Verification for Conditionals and Decisions must cover an ordinary case, an empty or missing case, invalid input, and the most important threshold. Predict each result before running it, then locate the first value that violates the contract when reality differs. Record the corrected case as a repeatable check and explain which product behavior should occur instead of allowing undefined, NaN, stale data, or silent failure to spread.

WORKED EXAMPLES

Read the decision before the syntax

Example 1: Primary worked example

Trace this Conditionals and Decisions example from validated input to returned value or visible effect before editing it.

function progressLabel(percent) {
  if (!Number.isFinite(percent) || percent < 0 || percent > 100) throw new RangeError("0–100 required");
  if (percent === 100) return "complete";
  if (percent >= 70) return "on track";
  if (percent >= 1) return "in progress";
  return "not started";
}
[0, 1, 70, 100].forEach(value => console.log(value, progressLabel(value)));

Example 2: Second worked example

This variation changes the shape of the problem so you can compare the underlying if contract instead of copying one solution.

function canPublish({ role, verified, suspended }) {
  const hasPublishingRole = role === "editor" || role === "admin";
  const accountIsUsable = verified === true && suspended !== true;
  return hasPublishingRole && accountIsUsable;
}
console.log(canPublish({ role: "editor", verified: true, suspended: false }));

How to trace this lesson

Write down the exact inputs used by Conditionals and Decisions.
Predict each returned value and observable effect before running the example.
Mark the first boundary where invalid or missing data could enter.
Verify the ordinary, empty, invalid, and threshold cases independently.

Common mistakes and corrections

Putting a broad threshold before a narrower one makes the narrower branch unreachable.: Make the if rule explicit and cover it with a focused example.
Changing several parts of the example before explaining the original result.: Make one change at a time and compare it with a written prediction.
Testing only the demonstration's happy path.: Add missing, invalid, empty, and boundary inputs that exercise the stated contract.

PRACTICE LADDER

Move from recognition to independent work

1
Handle invalid input with a guard clause
2
Test immediately around every threshold
3
Name complex boolean subconditions
4
Implement and test a progress classifier whose ranges have no gaps or overlaps.

Complete these in order. The final step should work without copying the lesson example; use the runner and lab below to test it.

Core rule

Applied boundary

RUNNABLE EXAMPLE

Change one assumption at a time

Predict the output, run the example, then change one input and one boundary in the Conditionals and Decisions example. Explain every changed result before continuing.

function progressLabel(percent) {
  if (!Number.isFinite(percent) || percent < 0 || percent > 100) throw new RangeError("0–100 required");
  if (percent === 100) return "complete";
  if (percent >= 70) return "on track";
  if (percent >= 1) return "in progress";
  return "not started";
}
[0, 1, 70, 100].forEach(value => console.log(value, progressLabel(value)));

function progressLabel(percent) {
  if (!Number.isFinite(percent) || percent < 0 || percent > 100) throw new RangeError("0–100 required");
  if (percent === 100) return "complete";
  if (percent >= 70) return "on track";
  if (percent >= 1) return "in progress";
  return "not started";
}
[0, 1, 70, 100].forEach(value => console.log(value, progressLabel(value)));

Press Run to execute your code.

DEBUGGING CHALLENGE

Locate the first incorrect value

Predict the failure and write your repair before revealing the explanation.

if (score >= 50) grade = "pass";
else if (score >= 90) grade = "excellent";

Reveal repair and explanation

if (score >= 90) grade = "excellent";
else if (score >= 50) grade = "pass";
else grade = "review";

The most specific high threshold must be tested before the broader passing range.

INDEPENDENT LAB

Build without copying the example

Implement and test a progress classifier whose ranges have no gaps or overlaps.

// Define small functions before composing the complete solution.
// Implement and test a progress classifier whose ranges have no gaps or overlaps.

// Define small functions before composing the complete solution.
// Implement and test a progress classifier whose ranges have no gaps or overlaps.

Press Run to execute your code.

Self-review checklist Handle invalid input with a guard clause Test immediately around every threshold Name complex boolean subconditionsWhat did you predict, observe, and change?

KNOWLEDGE CHECK

Explain the rule, not only the syntax

1. Why test 90 before 50 in an ordered grade chain? The first matching branch wins Numbers require a switch else runs first

2. Which evidence best demonstrates mastery of Conditionals and Decisions? A prediction, boundary tests, and an explained result A copied snippet with no changes One successful happy-path run

Loading saved work…

Code and answers save automatically. Guest work stays on this device; signed-in work syncs to your account. The runner is isolated, blocks network access, and stops long-running console programs.

Conditionals and Decisions | JavaScript Course | SovranCode

1. JavaScript Foundations

2. Functions and Collections

3. Objects and Structured Data

4. Browser Interfaces

5. Async and Reliable Applications

6. Application Engineering