Count only open tasks
A task list often contains a mixture of states. Today we will count only the open ones. Our first data set is deliberately small: open, done, open. The expected answer is two. We will express that rule with a helper function, an if statement, and a for loop. Then we will change the input to check cases where the same code should return zero or count every item.

Keep the data model simple
The input is a List of String values called statuses. We are not introducing task objects or database records yet. Each entry represents the status of one task. That keeps the new concepts visible: iterating over values, deciding whether a value matches a rule, and changing a counter. A typed list also tells us what each loop element will be, so the helper function can accept the same String type.

Name the decision
Our helper is called is Open. It accepts one parameter named status, declared as a String, and returns a Bool. Its body compares status with the string open. For an open task, the comparison returns true. For done, it returns false. Giving this question a name makes the condition in the main method easier to read. The helper does not change the input or print anything; it just returns the answer.

Static methods use double colon
The helper is declared with f n c, so it is a static method on Main. When we call it from the loop, we write Main, double colon, is Open. The argument between parentheses is the current status value. The method receives that value through its parameter and returns a Boolean. In Tinox, static calls use the double colon form. Calls through an object use a dot, which we will explore when we introduce instance methods.

Set up an accumulator
Before entering the loop, initialize open Count to zero using var. We need a mutable variable because each matching entry will increase the count. Placing it before the loop gives the whole loop access to the same running total. If we initialized it inside each iteration, we would repeatedly start over instead of accumulating a result. Its initial value also tells us what the answer should be when there are no matching entries.

Visit one element at a time
For status in statuses visits the entries in the list. On the first iteration, status is open. On the second, it is done. On the third, it is open again. The body between braces runs once for each of these values. We do not manually update an index in this example. The loop already gives us the value we need to ask our helper question.

Let a condition control the update
Inside the loop, the if statement calls our helper. When the result is true, the nested block adds one to open Count. When the result is false, that block is skipped. The loop itself continues with the next value. This distinction is important: skipping the counter update does not mean leaving the entire loop. We are applying the same decision independently to every entry in the input list.

Trace the values by hand
Start with zero. The first open value makes the helper return true, so the count becomes one. The done value returns false, so the count stays one. The final open value returns true, so the count becomes two. Once the loop finishes, println writes that final number. Tracing a tiny input by hand gives us an independent expectation before we trust the program's output.

Run the working example
The captured executable output is two, matching our trace. Notice that the print call appears after the loop, so we get one final answer. If we put it inside the loop, we would instead see intermediate states, which might be useful for temporary debugging but would change the visible behavior. When an example prints something unexpected, check both the calculation and the position of the output statement.

Check the boundary cases
We also built and ran three alternate inputs. An empty list produces zero because the loop body never runs. A list containing only done values also produces zero because every condition is false. A list containing three open values produces three. These checks do not prove every possible program property, but they exercise meaningful boundaries of the rule. They tell us more than running the same happy path several times.

Separate responsibilities
The helper answers one question. The condition decides whether to act on that answer. The loop decides how many inputs to visit. The accumulator remembers progress between iterations. Keeping those responsibilities distinct makes a small algorithm easier to change. Later, the rule might depend on a task object rather than a string, but the relationship between iteration, decision, and accumulated result can stay familiar.

Exercise: choose another state
Change the helper to recognize done instead of open, and give it a name that matches the new question. Update the call as well. For the original three entries, predict a result of one. Then try the empty list and predict zero. If the result surprises you, trace the values exactly as we did together. In the next episode, we will keep this habit of checking outcomes while building our first annotation driven HTTP endpoint.
