Until now your code ran in a straight line: from the first statement to the last, never taking a detour. That is enough to describe a Taller Nómada task, but not to reason about it. Marta does not want the program to repeat back what she already knows: she wants it to tell her which of her tasks are at risk, whether Iván can mark a task as done, or whether the creation form contains an invalid value. All of those are decisions, and a decision in JavaScript is written with a conditional statement. In this lesson you will learn to branch the flow with if, else and else if, to build compound conditions that read well, to keep your code flat instead of nesting it until it becomes unreadable, and to decide when a ternary improves the code and when it makes it worse.

1. From straight-line flow to branching
2. The if statement
3. else: the alternative path
4. else if: chains of decisions
5. Compound conditions with &&, || and !
6. Parentheses: the difference between correct and readable
7. Conditions on truthy and falsy values
8. The nesting problem
9. Guard clauses and early exit
10. The ternary operator and its limits
11. Case study: classifying a task's urgency
12. Case study: validating a status change (R6)
13. A decision table for the business rules
14. Common Mistakes and Tips
15. Exercises
16. Conclusion

In JavaScript Syntax and Basic Concepts you saw that JavaScript executes statements top to bottom, one after another. A control structure breaks that linearity: it lets certain statements run only under specific circumstances, or run many times.

Control structures fall into two families:

This lesson covers selection with if. The switch arrives in Switch Statements and iteration in Loops: for, while, do-while.

The simplest form: a condition and a block that runs only if that condition is true.

Anatomy, piece by piece:

• if is the reserved word. It is not strictly required to sit next to the parenthesis, but it is always written as if (.
• (estimatedHours > 40) is the condition. The parentheses are mandatory. Inside goes any expression that produces a value; JavaScript converts it to a boolean exactly as Boolean() did in Type Conversion and Comparisons.
• { ... } is the block that runs if the condition is true. With let and const, anything declared inside exists only inside.
• There is no ; after the closing brace. An if is a block statement, not an expression.

The output of the example:

If you change 46 to 12, the warning does not appear and only the second line is printed. The program chose not to run a piece of code.

JavaScript lets you drop the braces when the body is a single statement:

It works, but it is a classic source of bugs. Look at what happens when you add a second line:

The indentation suggests that both lines belong to the if, but indentation means nothing in JavaScript. Without braces, the if governs the first statement only; the second is ordinary code that always runs. The bug is invisible when you read it and obvious when you run it.

Course rule: always use braces, even when the body is a single line. It costs nothing and removes an entire category of bugs.

else defines what to do when the condition is false. It has no condition of its own: it means "in any other case".

Exactly one of the two blocks runs, never both and never neither.

When there are more than two paths, conditions are chained with else if. Turning a task's priority into a numeric weight is the project's canonical example:

Three important details:

1. The conditions are evaluated in order and the chain stops at the first true one. If priority is 'high', the other two comparisons never even run. Order matters.
2. The final else is the safety net. It catches the values you were not expecting: a 'HIGH' in uppercase, an undefined, a typo. Without it, weight would stay undefined and the failure would surface much later, somewhere else, disguised as NaN.
3. let weight; goes before the if. If you declared const weight = 3; inside the block, that variable would exist only inside that block and would vanish on the way out. Declaring outside and assigning inside is the usual pattern.

Technically else if is not a new construct: it is an else whose body is another if. It is written on the same line by convention, so that the chain reads as a list of cases rather than a staircase.

In Basic Operators you learned the logical operators and their short-circuiting. Inside an if is where they show their full value.

Rule R10 of the project says: an overdue task (dueDate in the past and a status other than 'done') is highlighted. Those are two conditions that must hold at the same time, so they are joined with &&:

Remember from The Course Project why dueDate < TODAY works without conversions: the ISO format 'yyyy-mm-dd' sorts alphabetically the same way it sorts chronologically.

With || we express "any of these situations justifies reviewing the task":

And ! inverts a condition. These two lines are equivalent:

The second one is clearly better. Use ! to negate boolean variables, not to negate comparisons: that is what !==, <= and >= are for.

&& has higher precedence than ||, just as * has higher precedence than +. That means this condition:

groups like this:

That may be what you meant, or it may not. The problem is that whoever reads the code cannot tell. Compare it with the other possible grouping:

With priority = 'high' and estimatedHours = 5, the first version gives true and the second false. They are different conditions that look very much alike.

Rule: as soon as a condition mixes && and ||, write the parentheses even though precedence already does the right thing. They are not for the engine: they are for the person who reviews the code six months from now.

When a condition grows too large, the best tool is not more parentheses but named boolean variables:

The final if now reads like a plain English sentence: it is open, and it is either overdue or important. Each intermediate variable documents one business idea, and you can print it separately when something does not add up. This technique —giving names to the pieces of a condition— is the single biggest readability win in real code.

In Type Conversion and Comparisons you saw the eight falsy values: false, 0, -0, 0n, '', null, undefined and NaN. Everything else is truthy. An if applies exactly that conversion to its condition.

This lets you write very short checks:

Convenient, but dangerous, because if (value) lumps together very different situations. Watch what happens with the project's fields:

Two direct consequences for Nómada Tasks:

estimatedHours can be a valid number and still be falsy. If one day 0-hour tasks were allowed, if (estimatedHours) would treat them as if the field were missing. The honest check is explicit:

An empty array is truthy. if (tags) gives true even when there is not a single tag, because the array exists. Since tags is always an array (never null), what you have to look at is its length:

Practical rule: use if (value) only when you genuinely mean "there is something usable here" and none of the falsy values is legitimate for that field. In every other case, write the full comparison: === null, > 0, .length === 0, !== ''. The code gains in clarity what it loses in brevity.

An if can contain another if. The first time you need it, the result looks reasonable:

This code works, but it has three serious problems:

1. The important case is buried. To work out when "Overdue and assigned" gets printed you have to mentally reconstruct three accumulated conditions.
2. The else branches are far from their if. The else on the last lines belongs to the first if, twenty lines further up.
3. Every new level multiplies the paths. Three levels already give eight possible combinations.

This shape is known as arrow code, because the indentation draws an arrowhead pointing right. It is one of the most reliable signs that a piece of logic needs rewriting.

The alternative is the guard clause: instead of nesting the good case inside successive checks, you discard the exceptional cases first and leave the main path at the end, unindented.

We rewrite the previous example as a flat chain of else if, ordered from the most exclusive case to the most general:

Same behavior, a single level of indentation and four cases that read like a list. Each line answers one question and the chain stops at the first affirmative answer, so the later conditions can take everything above them for granted: by the time dueDate < TODAY is evaluated, we already know for certain that the task is not done and that it has an assignee.

A second pattern, very useful in validations, is to accumulate the reason for rejection in a variable:

title.trim() removes the whitespace at both ends, so a title made only of spaces is detected as empty: exactly what rule R2 requires.

A note about the name. "Early exit" describes leaving a block of logic immediately as soon as an invalid case is detected. Its canonical form uses return inside a function, and that tool arrives in Defining and Calling Functions. In the meantime, the flat else if chain gives you the same main benefit —zero nesting and ordered cases— with what you already know. Once you know functions, this same code will turn into three lines with return and it will feel natural.

The ternary condition ? valueIfTrue : valueIfFalse you saw in Basic Operators is an expression: it produces a value. That is the key to knowing when to use it.

Use it to assign or interpolate a value, where it shines:

With an if/else you would need five lines and a let variable that never changes again afterwards. The ternary lets you keep const, which is always preferable.

Do not use it to run actions. This works but it is an abuse: the ternary is designed to produce values, not to pick side effects.

Do not nest it more than once. A ternary inside another is still readable if you format it in a column, but three are not:

When the chain of cases grows, the right construct is an if/else if or a switch, which you will see in lesson 02-03.

Marta needs an urgency label that combines two signals: the priority and the days left before the due date. This is the project's first real piece of business logic.

What you need to understand here:

• new Date(dueDate) - new Date(TODAY) takes advantage of something you already know: when the - operator is used, JavaScript converts each date to its number of milliseconds since 1970. Subtracting them gives the distance in milliseconds; dividing by MS_PER_DAY turns it into days. It is the only place in the project where we use Date, exactly as announced in lesson 01-08.
• The order of the chain is business logic, not whim. A task that is done is never urgent even if it is past its due date, so isClosed comes first. An overdue one is critical with no further checks, so it comes second.
• The four boolean variables make the chain self-explanatory. Without them, the fourth condition would be (daysLeft >= 0 && daysLeft <= 3) || priority === 'high', correct but opaque.

Rule R6 says that only the life-cycle transitions are valid. Remember the diagram from lesson 01-08:

Translated into conditions: four transitions are valid and no others. Iván tries to move a task straight from 'pending' to 'done', and the program has to reject it with an understandable reason.

Notice the structure: two guards at the start (non-existent status, repeated status), four permitted cases in the middle and an else that rejects everything else. Rejecting by default is the right policy in a validation: if tomorrow someone adds a new status and forgets its transition, the system will reject it instead of accepting it silently.

This chain of six else if is long, and there is a reason: each branch compares two variables. In lesson 02-03 you will see that a switch does not improve this particular case, and in Module 4 you will solve it with a lookup object in four lines. For now, this version is explicit and correct, which is what matters.

Before writing a complicated if it pays to draw a decision table: one row per case, one column per condition and one column with the result. Here is the one for the validations Nómada Tasks applies when accepting a new task.

The table translates almost mechanically into a chain of guards: each row is an else if that assigns the rejection message. Writing it before you program has two advantages: you discover forgotten cases while you fill it in, and it gives you the list of tests you will run in Module 8.

Using = instead of == or ===. The classic mistake.

= assigns, it does not compare. The expression evaluates to 'done', which is truthy, so the condition always holds and on top of that you have destroyed the original value. With const you will get a TypeError that saves you; with let, a silent bug. Always read === out loud as "is equal to" and = as "gets".

Comparing with == out of habit. '0' == false is true and null == 0 is false. Always use ===, as was established in lesson 01-07.

Putting a ; after the condition.

The ; is the empty body of the if, and the block that follows is a loose block that runs no matter what. There is no error and no warning.

Chaining comparisons the way you would in math. if (0 < hours < 40) does not do what it looks like: it evaluates 0 < hours, gets true or false, and compares that with 40 after converting it to 1 or 0. It always gives true. The correct form is hours > 0 && hours < 40.

Forgetting the final else. If an else if chain assigns a variable, without an else that variable can be left as undefined. Always add a default case, even if it only logs an error.

Not repeating the variable in each comparison. priority === 'high' || 'medium' does not compare against 'medium': it evaluates priority === 'high' and, if that is false, returns 'medium', which is truthy. The condition always holds. You have to write priority === 'high' || priority === 'medium'.

Tip: turn long conditions into named booleans. It is the technique from this lesson with the biggest impact on real code.

Tip: order your chains from the most specific case to the most general. If the general case goes first, the specific ones are never reached.

Exercise 1 — Workload label

Marta wants to know at a glance whether a task is manageable. Write an if/else if chain that, from estimatedHours, assigns one of these values to a variable workload, and rejects with an error message the values that violate rule R3:

Test it with 2, 12, 30 and -3.

Exercise 2 — The task traffic light

With these variables, compute a variable trafficLight with the value '🔴', '🟠' or '🟢' according to these rules, using named boolean variables so that the final if reads like a sentence:

• 🔴 if the task is not done and its due date has already passed.
• 🟠 if it is not done, the date has not passed and the priority is 'high'.
• 🟢 in every other case.

Then print a line with the traffic light and the title. Solve the final part (choosing the text that goes with the traffic light: 'urgent', 'attention' or 'on schedule') with a ternary where that is reasonable.

Exercise 3 — Who can change the status

Extend the validation from section 12 with an additional Taller Nómada rule: only the task's assignee or Marta (the coordinator) can change its status. Add the variables assignee and user, and make the validation reject the change with a clear reason when the user has no permission. Be careful with the order: checking permission has to come before checking the transition, because it makes no sense to explain that the transition is invalid to someone who could not touch the task in the first place.

Test it with: assignee 'Iván' and user 'Lucía' (it must reject on permission), and assignee 'Iván' and user 'Marta' with the transition in-progress → done (it must allow it).

Exercise 1

The key is to discard the invalid values first. Once that guard is passed, we know that estimatedHours is between 0 (exclusive) and 40, so the following conditions only need the upper bound: <= 4, <= 15 and the else. There is no need to write estimatedHours >= 5 && estimatedHours <= 15, because reaching that branch already guarantees it is greater than 4. That implicit accumulation is the great advantage of else if chains over separate if statements.

With -3: it enters the first branch, workload is 'invalid' and the error is logged. With 2: 'light'. With 30: 'heavy'.

Exercise 2

The three boolean variables turn the if into something you read straight off: "if it is open and it has expired...". Without them, the first condition would be status !== 'done' && dueDate < TODAY, which forces you to read it twice.

The double ternary for note is at the limit of what is acceptable: three cases on a single variable, visually aligned. If there were a fourth traffic light, the right answer would be an if/else if or the switch from the next lesson.

Exercise 3

With user = 'Lucía' and assignee = 'Iván', the first guard cuts things short immediately: ✗ Lucía cannot modify a task belonging to Iván. And notice that whether the transition was valid is not even evaluated, which is exactly what the exercise asked for.

hasPermission deserves its own variable because it expresses a business concept —authorization— that is different from the concept of a valid transition. When permission gets more complicated tomorrow (for example, also allowing an assigned reviewer), only that line changes.

The ternary in the console.log is well used: it picks a value —the ✓ or ✗ prefix— inside a template, which is exactly what it is for.

Your code now makes decisions. You know how to write an if with braces every time, add an else for the alternative path and chain else if to classify into more than two cases, taking advantage of the fact that each branch assumes everything the previous ones ruled out. You know how to combine conditions with &&, || and !, add parentheses for readability even when precedence is already correct, and —most important of all— give names to the pieces of a condition so that the final if reads like a sentence from the business.

You also know how to avoid two frequent traps: trusting truthy/falsy when 0, '' or an empty array are legitimate values, and nesting if inside if until you draw an arrow in the margin. The flat chain of guards is your tool against nesting, and the ternary is your tool for assigning one of two values, never for running actions and never for chaining four cases.

Applied to the project, you have already implemented two real pieces of Nómada Tasks: the urgency classification that combines priority and days left, and the status transition validation of rule R6, permissions included.

But notice something: all of that logic applies to a single task. Marta has a backlog of six, and next month she will have forty. Copying the urgency block forty times is not an option. That is solved in Loops: for, while, do-while, where you will learn to repeat a block of code as many times as necessary and to walk through all the workshop's tasks to add up their hours, find the most urgent one and count how many each person is carrying. With conditionals inside loops you will finally have a program that reasons about real data.