Exercise 3 of 10 · Conditionals (if/else)

Parking Meter Status

What you will make

A program that subtracts elapsed time from paid time and prints whether the meter is OK, almost expired, or expired.

The one new idea: Branching with if / else if / else and comparison operators (<=, etc.)

Deciding between two or more outcomes based on a number is one of the most common things any program does, from meters to game logic to form validation.

Go straight to the code ↓

An if / else if / else chain in Go checks its conditions in order, top to bottom, and runs the code under the first one that's true — everything after that is skipped. That makes the order and the exact comparison operators you choose matter a lot: a threshold that's too wide will swallow cases meant for a later branch, and getting the direction of a subtraction backwards can flip a positive number of minutes into a negative one.

Worked example

Here's the same meter logic with different numbers, landing on a different branch:

package main

import "fmt"

func main() {
	minutesPaid := 10
	minutesElapsed := 10

	remaining := minutesPaid - minutesElapsed

	fmt.Println("Parking meter check")
	if remaining <= 0 {
		fmt.Println("Status: EXPIRED")
	} else if remaining <= 5 {
		fmt.Printf("Status: ALMOST EXPIRED (%d minutes left)\n", remaining)
	} else {
		fmt.Printf("Status: OK (%d minutes left)\n", remaining)
	}
}

Output

Parking meter check
Status: EXPIRED

With 10 minutes paid and 10 elapsed, remaining is exactly 0, which the first condition (remaining <= 0) catches — showing why <= rather than < matters for the boundary case.

Your turn

The starter program computes remaining and then checks it against two thresholds, but one line computes the subtraction backwards and another line uses a threshold that doesn't match what "almost expired" should mean. Fix both marked lines so a meter with a small but positive number of minutes left reports the right status.

If something goes wrong

If every run reports EXPIRED even when it shouldn't, check the subtraction order first — a negative remaining will always trip the first branch. If ALMOST EXPIRED shows up for values that should be OK, look at the else-if threshold; it should only catch small numbers, not the whole range up to fifty. And if you see no output at all for some values, make sure the final else block is still there to catch everything the earlier branches don't.

Write your code

Runs in your browser. Press Run (or Ctrl/Cmd+Enter) and the output is checked for you.

Ctrl/Cmd+Enter to run

Press Esc then Tab to move keyboard focus out of the code editor.

Ready

Output will appear here after you run your code.

The runtime is starting in the background. You can type now — it will be ready before you are.

The answer appears here once you have run your code at least once.

Things that often go wrong here

Subtracting in the wrong order.: a - b and b - a give opposite-sign results; 'time remaining' has to be paid time minus elapsed time, not the reverse.
Picking an else-if threshold that overlaps the first condition's range.: Branches are checked top to bottom, so if an earlier condition is too broad, later branches never get a chance to run for values that should reach them.
Using = instead of == inside an if condition.: Go doesn't even allow assignment as a boolean condition, so this is a compile error, not a silent bug — but it's an easy typo to make.
Forgetting the else branch entirely.: Without a final else, values that don't match any earlier condition produce no output at all, which is easy to miss when testing only a few cases.

Want a blank editor instead? Open the Go playground.