8 Fundamental Programming Techniques

Start with a systematic process

Programming becomes more reliable when a problem is treated as a sequence of small, testable decisions. Begin by identifying the required inputs, outputs, rules, and constraints. Work through ordinary, boundary, and invalid examples before implementation.

Then decompose the task into independent operations, choose representations suited to those operations, describe the procedure in plain language or pseudocode, and implement incrementally. Compare actual results with expected results and refine clarity, correctness, and efficiency without changing the required behavior.

For example, an average-of-scores task should specify what counts as a valid score and what happens when no valid scores remain. Making that decision explicit prevents an undefined division or a misleading result.

Takeaway: A precise problem description and a small set of examples are the foundation for a dependable program.

Reason about algorithms and efficiency

An algorithm is a finite, precise procedure for solving a problem. Its quality can be judged by correctness, termination, clarity, efficiency, and general applicability.

Decomposition makes reasoning manageable: a large task can be divided into functions that each solve one part. An invariant provides another reasoning tool. For a running maximum, the invariant can be that the current largest value is the greatest value examined so far. If the invariant is established before the loop and preserved after each iteration, it supports the conclusion that the final result is correct.

Efficiency concerns how work grows with input size. A linear search has worst-case growth of $\mathrm{O}(n)$, binary search on sorted data has search-step growth of $\mathrm{O}(\log n)$, comparison-based sorting commonly has growth of $\mathrm{O}(n\log n)$, and a simple selection sort has growth of $\mathrm{O}(n^2)$. Big-O notation describes growth rather than exact elapsed time, so constant factors, memory usage, and implementation details still matter.

Takeaway: Use decomposition and invariants to establish correctness, then compare approaches by how their resource use grows.

Represent data and control behavior

A variable is a name bound to an object, so names should communicate purpose. Names such as subtotal, quantity, and is_member make later control flow easier to understand.

Choose a collection according to the operation required:

• A list is an ordered, mutable sequence for items that may change or must be processed in order.

• A tuple is an ordered, immutable sequence for a fixed group of related values.

• A set stores unique values and is useful for membership tests or removing duplicates.

• A dict maps identifying keys to values and is useful for direct lookup.

Control flow expresses decisions and repetition. Conditional statements handle alternatives, for loops process items, range() produces sequences of positions or numbers, and break and continue alter loop progress. Validate assumptions early, such as rejecting a nonpositive quantity before performing a calculation.

Takeaway: Clear names, suitable collections, and explicit control flow turn data and rules into readable behavior.

Build modular functions

A function should perform one coherent task and communicate through parameters and a return value. Its contract should make four things clear: accepted inputs, returned output, side effects, and possible errors.

Prefer a calculation function that returns a result rather than printing it. For example, a total-calculating function can return the sum, while a separate presentation step formats and displays that value. This separation allows the same calculation to serve a command-line interface, a file-processing program, or an automated test.

Keep functions small and cohesive, pass required data as arguments, and avoid unnecessary global state. When side effects are necessary, isolate them in a focused function responsible for a task such as reading a file or displaying a report. Validate arguments at the boundary of the function and raise a specific error when the contract is violated.

Takeaway: A clear function contract makes code easier to test, reuse, compose, and maintain.

Search and sort deliberately

A linear search checks items from left to right until it finds a matching value or reaches the end. It works on unsorted collections and is often appropriate for short inputs. If the target is absent or appears at the end, the search may inspect every item, giving worst-case growth of $\mathrm{O}(n)$.

Binary search requires the data to be sorted. It compares the target with the middle item, then discards either the lower or upper half of the remaining range. Repeating this process gives search-step growth of $\mathrm{O}(\log n)$, but the sorted-data requirement must be maintained.

Python's sorted() function returns a new list, whereas list.sort() changes an existing list in place. Both accept a key function, so records can be ordered by a selected field rather than by manually comparing complete records. A simple selection sort repeatedly chooses the smallest remaining item; its $\mathrm{O}(n^2)$ growth makes it mainly useful for illustrating the pattern rather than for large inputs.

Takeaway: Match the search method to the data's ordering and choose built-in sorting tools when practical.

Handle files and failures safely

File operations and external input are failure-prone boundaries. Use a context manager with file access so cleanup occurs automatically, including when an exception interrupts the operation. Specify the encoding when reading text, and treat missing files, malformed content, and invalid values as expected possibilities rather than impossible events.

Handle an exception where the program can respond meaningfully. Catch specific exception types instead of using a broad handler that could hide programming errors. A lower-level file error can be translated into a meaningful application-level error while preserving the original cause. Input conversion can be placed inside a loop that asks again after a ValueError.

Python distinguishes syntax errors from exceptions raised during execution. The try statement supports except for handling, else for code that runs when no exception occurs, and finally for cleanup that must run regardless of success or failure. Explicit raise statements enforce function contracts.

Takeaway: Make resource cleanup automatic, validate at boundaries, and handle only failures the program can explain or recover from.

Test and debug systematically

Testing asks whether a program behaves correctly for selected inputs. Include typical cases, boundary cases such as an empty collection or a single item, invalid cases such as malformed text or a missing file, and a regression test for each defect that has been fixed.

An assertion states an expected condition. Automated suites can organize test cases, fixtures, assertions, and test discovery; test methods conventionally begin with test. Test computational functions independently from input and presentation code whenever possible.

Debug systematically:

1. Reproduce the failure with the smallest input that still fails.

2. Read the complete traceback, including the exception type and line number.

3. Check assumptions about types, values, indexes, and file contents.

4. Inspect intermediate values with temporary output, a debugger, or logging.

5. Form one hypothesis at a time.

6. Change the code, rerun the failing test, and then run the full test set.

7. Remove temporary diagnostic output after the defect is fixed.

A traceback identifies where execution failed, but the original incorrect value may have been created earlier. The location of failure and the location of the defect are not always the same.

Takeaway: Use representative tests to expose incorrect behavior and evidence-based debugging to locate its cause.

Combine the techniques in a complete program

A complete word-frequency report illustrates how the techniques fit together. One function extracts lowercase alphabetic words, another aggregates them in a dictionary, a third orders and limits the results, and a coordinating function manages file access and report formatting. A separate entry point handles user interaction and presents a recoverable file error.

The design is modular because each function has one principal responsibility:

• Extraction converts text into a sequence of words.

• Aggregation maps each word to its frequency.

• Ordering selects the requested number of results.

• Coordination combines file input, computation, and formatting.

• Presentation handles interaction and user-facing errors.

A deterministic tie-breaking rule is important. If two words have equal counts, alphabetical order makes the output predictable and straightforward to test. Tests should check extraction, counting, ordering, empty input, invalid limits, and file failures.

This structure demonstrates a general pattern: isolate input and output, keep computational functions deterministic, make assumptions explicit, and connect the pieces through clear return values.

Takeaway: Small, deterministic functions can be combined into a complete program without sacrificing testability or clarity.