
When we reach the point in our high school computer science curriculum where students have to stop just making things work and start making things better, the calendar always seems to be working against us. It is the time of year when project deadlines tighten and the pressure to move on to more complex algorithms grows. For teachers in districts like Capistrano Unified, Los Angeles Unified, Moreno Valley Unified, and Carlsbad Unified, this is the standard stretch where we ask students to justify their technical decisions. It is the same across the state. Whether you are using this as a whole-class assignment or helping a student who missed the week catch up on the logic behind programming, Choosing the Best Way to Write Code is a solid resource that fits into a single period.
Selecting the right tools for the job
This lesson centers on the idea that there is rarely one perfect way to write a program, but there are definitely better ways to manage a codebase. The objective is for your students to pick the best control structures by considering how simple they are to build, how fast they run, and how easy they are for another human to understand. Students start with a scenario about a small farming village tracking harvests, which is a great, low-stakes entry point for understanding why we choose specific repetition methods. The lesson defines core vocabulary clearly: control structure, readability, performance, and implementation complexity.

I appreciate that the lesson does not just focus on raw speed. In a high school computer science control structures lesson, it is tempting to obsess over cycle counts, but the lesson material hits the nail on the head: “Optimized code is great, but readable code is what lets a company build big things safely.” Students walk through a worked example showing how a ternary operator can condense a four-line if-else block into a single line. It is a classic moment where students realize that being “clever” is not the same as being “effective.”
Connecting to standards
This work is essential for meeting CA.CS.9-12.AP.14. This California-adopted standard asks students to justify the selection of specific control structures by identifying tradeoffs associated with implementation, readability, and performance. In practice, this means moving students away from “it works” toward “I chose this loop because it is easier for my team to maintain without sacrificing speed.” It is a difficult shift for teenagers who are often just happy to see the compiler stop throwing errors, but the guided practice setup involving an inventory system interface provides a concrete context for them to exercise this judgment.
Where students often slip
In my experience, the biggest hurdle for students is overestimating how much they need to optimize. They often think that shorter code is always better, ignoring the fact that if a one-line solution is impossible for their peers to read, it is a liability. This lesson keeps them grounded by forcing them to look at the interface they are building and consider the human element of software engineering. It is an honest look at the trade-offs that professional developers face every day, and it keeps the technical jargon to a minimum. Because this lesson is self-contained, it is an excellent choice for a substitute day or for an independent study module when you need to ensure a student is hitting the standard without requiring your constant supervision during a busy week.




