Designing Focused Functions | CodeSignal Learn

Designing Focused Functions | CodeSignal Learn

Introduction: One Job, Many Steps

Welcome back to Writing Complex Python Functions! We have arrived at the fifth unit, and the pieces we collected along the way are about to come together. So far, each function has done one small thing: branched, accumulated, filtered, or copied. Real work rarely arrives in such neat portions. A single request such as "summarize these prices" quietly contains validation, filtering, a loop, and several running totals at once. Our program for this unit ships with one function, summarize_prices(prices, min_price=0), and two calls that print: text kept 4, total 96.5, largest 45.0 kept 2, total 75.0, largest 45.0 That function's body runs about eighteen lines, which instinctively feels like "too long." So here is the question that guides the whole unit: How do we tell a legitimately long function from one that should be split? The answer is not line count; it is the number of jobs .

The Four Regions of a Long Function Body

Let us meet the shipped function in full, then immediately stop reading it as eighteen unrelated lines. Python def summarize_prices(prices, min_price=0): """Summarize the prices that reach min_price. Preconditions: prices contains only non-negative numbers (validation arrives in Practice 3). Args: prices: A list of non-negative numbers. min_price: The smallest price to include in the summary. Returns: A one-line summary string with how many prices were kept, their combined total, and the largest single price. """ kept = 0 # accumulators start before the loop total = 0.0 largest = 0.0 for price in prices: if price < min_price: continue # skip this price, keep looping kept += 1 total += price if price > largest: largest = price return ("kept " + str(kept) + ", total " + str(total) + ", largest " + str(largest)) Read from top to bottom, the body splits into exactly four regions: the docstring contract, the accumulator initializations, the loop body (skip plus updates), and the single post-loop return . Ask what the function does, and the answer is one sentence: It summarizes a list of prices. One job, four regions, many lines. This shape is a reusable template. Any "walk a list and report on it" function can be poured into it, and keeping the regions in this same order is what makes a long body skimmable for the next person who opens the file.

Sign up

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Accumulators Must Be Born Before the Loop

Region two is only three lines, and their position is the entire point. Recall the Unit 2 pattern: create accumulators once above the loop, update them inside, then read them after. Here we apply that same idea to several running values at once. Python kept = 0 # accumulators start before the loop total = 0.0 largest = 0.0 for price in prices: All three names are created once per call and then survive across every iteration. Move kept = 0 into the loop body, and every iteration wipes it clean: The final summary would describe only the last price instead of all of them. That position bug is the classic accumulator mistake, and it is especially easy to miss when several counters share the same loop. Pre-loop placement also covers empty input. With prices = [], the loop body never runs, yet the three names already exist, so the return reports kept 0, total 0.0, largest 0.0 instead of crashing with UnboundLocalError . One small detail: total = 0.0 rather than 0 is why the output reads 96.5 and not an integer-looking value. Until Practice 3 adds negative-price validation, the shipped function assumes every price is non-negative, so largest = 0.0 is a safe starting floor: any kept price will be at least that large. (Later you could use a None sentinel instead when negatives are allowed; we keep 0.0 here because the contract states the precondition clearly.)

Filtering Inside the Loop: continue vs. return

Region three opens with a two-line skip, and this is where the choice of keyword decides whether the answer is right. Python for price in prices: if price < min_price: continue # skip this price, keep looping kept += 1 total += price if price > largest: largest = price As we saw in the loops unit, return inside a loop abandons the whole traversal, which is only correct when a single item completes the answer, as in a search. Here, a filtered summary depends on every element, so we reach for continue : It abandons only the current price and jumps straight to the next iteration. Tracing summarize_prices(prices, min_price=20) on [30.0, 12.5, 45.0, 9.0] : 30.0 is kept, 12.5 is skipped so neither counter moves, 45.0 is kept, and 9.0 is skipped, giving kept 2, total 75.0, largest 45.0 . Every surviving price then updates all three accumulators, including the nested if price > largest: check, the standard maximum-tracking pattern: largest climbs from 30.0 to 45.0 and stays there because 9.0 > 45.0 is false.

Two Kinds of Skipping: Validation vs. Business Rules

Notice that min_price is a business rule : The caller chooses the cutoff, and a price below it is perfectly valid data that simply does not belong in this summary. A negative price is a different matter entirely: It is nonsensical no matter what the caller asked for. That second kind of check is validation, and it belongs as the first statement of the loop body. Python for price in prices: if price < 0: continue # invalid data: never counted if price < min_price: continue Validation-first is still the right habit, but not because two sequential if / continue checks somehow "miss" each other. With the structure above, a failed cutoff simply continues to the next iteration; if the checks were swapped, a negative price that failed the cutoff would still be skipped by continue, and a negative price that passed a negative cutoff would still hit the validation line on the same iteration. Either way, bad data is discarded. So why put validation first? It makes the "reject invalid input" rule semantically explicit and independent of business filtering : Readers see "is this even a price?" before "does it meet the caller's cutoff?" That separation stays reliable even if someone later merges the checks with or, nests them differently, or adds more filters. Putting validation first is the same instinct as the guard clauses from the branching unit, applied once per item instead of once per call.

Practice Preview: Adding a Guarded Average

The shipped summarize_prices function reports kept, total, and largest; it does not calculate or return an average yet. In Practice 2, you will extend that focused function with one derived statistic. Python average = 0.0 # add above the loop # ... existing loop updates kept and total ... if kept > 0: # derive after the loop average = total / kept The guard is mandatory because a cutoff can filter out every price, leaving kept at 0 . The denominator must be kept, not len(prices), because only kept prices contributed to total . Initializing average to 0.0 before the loop gives the extension a defined result when no price survives. This is a preview of the next practice, not a hidden step in the function used by this lesson's two output lines.

One Exit Point and a Contract That Matches It

The final region is a single return, dedented back to function-body indentation so it runs once, no matter how many prices the loop walked. Python return ("kept " + str(kept) + ", total " + str(total) + ", largest " + str(largest)) Each accumulator is converted with str(...) and concatenated into one line; the surrounding parentheses simply let the expression span three readable lines. One return after the loop is a natural fit for these "walk the list, then report" examples: There is exactly one place to look when the output is wrong. That is not a universal Python rule—guard-clause early returns at the top of a function are still fine elsewhere—but for accumulator-driven summaries, a single post-loop exit keeps the four-region shape easy to skim. Now re-read the docstring as a caller who cannot see any of this: Args: explains both parameters, and Returns: explains the summary string. The shipped version also states the non-negative precondition; when Practice 3 adds the negative-price skip, the contract must name that silent skip as well. That gives us this unit's honesty rule: any invalid input a function silently skips must be named in its docstring. Bad data that quietly vanishes is a surprise the caller has no way to predict.