1 Programming Fundamentals and Problem Solving

From Problems to Algorithms

Programming is best understood as a problem-solving process rather than as the memorization of one language's syntax. A reliable workflow is:

1. Understand what the problem requires.

2. Design an algorithm.

3. Represent the design with pseudocode or a diagram.

4. Implement the design in a programming language.

5. Test, debug, and improve the result.

An Algorithm is a finite, ordered set of precise steps. It should identify its inputs, processing, and outputs, and it should have clear steps, a stopping point, and a correct result. For example, to find the largest value in a nonempty list, treat the first value as the largest seen so far, compare each remaining value with it, replace it when a larger value is found, and return the final largest value.

Pseudocode lets you express this logic without committing to a particular programming language. It can use structures such as FOR, IF, RETURN, and END while leaving punctuation and library details for the implementation stage.

A reliable design process uses Decomposition to divide a large task into smaller responsibilities. A grade-report program, for example, could separate reading scores, validating scores, calculating an average, assigning a letter grade, and displaying the report. Working from small examples clarifies requirements and provides initial test cases. An Edge case such as an empty list, a single-item list, a negative value, a duplicate, or division by zero can expose assumptions that ordinary examples do not reveal.

Efficiency is another design consideration. A linear search may inspect up to every item, often described as $O(n)$, while binary search repeatedly halves a sorted collection, often described as $O(\log n)$. The faster approach is useful only when its requirements, such as sorted data, are satisfied.

Takeaway: Define the problem precisely, break it into manageable parts, express the logic clearly, and consider correctness, boundary behavior, and efficiency before writing detailed code.

Data, Expressions, and Decisions

Once the algorithm is clear, organize the program so that input, processing, and output are easy to distinguish. A common structure is to declare needed data, obtain input, validate it, process it, and display the result.

A Variable is a named reference to a value. Assignment evaluates the right-hand side first and then stores the result. For example, if count begins at $0$, the statement count ← count + 1 computes the old value plus $1$ and stores the new value back in count.

A data type identifies the kind of value and the operations that make sense for it. Common types include:

• An integer, such as $42$.

• A floating-point number, such as $3.14$.

• A string, such as "hello".

• A Boolean, whose value is either true or false.

• An array or list containing an ordered collection.

• An object containing related properties and possibly methods.

An expression combines values, variables, operators, or method calls to produce a result. For example, width * height computes an area, while score >= passingScore produces a Boolean result. The type of a value affects an operation: adding numbers performs arithmetic, while adding strings may concatenate them. Descriptive names such as totalCost, studentCount, and isValid make expressions easier to understand.

A conditional selects instructions based on a Boolean expression. Conditions can compare values using equality, inequality, greater-than, or less-than relationships. Boolean operators combine conditions: AND requires both conditions to be true, OR requires at least one to be true, and NOT reverses a Boolean value. In an IF and ELSE IF chain, conditions are checked from top to bottom, and the first true branch is selected.

Takeaway: Clear data representation and readable Boolean logic make a program's decisions easier to predict and maintain.

Repetition and Reusable Behavior

Repetition prevents the same instructions from being written separately for every item or attempt. A loop is appropriate when a task must be performed repeatedly.

A count-controlled FOR loop works well when the number of repetitions or the items to process are known. A collection-oriented loop can process every score in a list and add it to a running total. A WHILE loop repeats as long as its condition is true, so its body must change the relevant state or input must change; otherwise, the program may enter an infinite loop. A REPEAT...UNTIL or DO...WHILE form checks its condition after the body, so the body runs at least once. BREAK ends a loop early, while CONTINUE skips the remainder of the current iteration. Both should be used sparingly when they would make control flow harder to follow.

A function is a named, reusable block of instructions that performs one coherent task. The values supplied at a call are arguments, while the names in the definition are parameters. A function may return a value, modify data, display output, or perform another action. Functions reduce duplication, give operations meaningful names, simplify testing, and limit how much logic a reader must understand at one time. A function such as calculateTax communicates its purpose more clearly than one large routine handling unrelated tasks.

Scope determines where data can be accessed. A local variable belongs to the function or block where it is declared. Global state may be accessible throughout a program, but excessive global state makes behavior harder to predict and test.

An array stores values in an ordered collection accessed by position. In many languages, indexing begins at $0$, so a three-element array has valid indexes $0$, $1$, and $2$. Common operations include reading, replacing, adding, removing, searching, sorting, finding the length, and iterating. Accessing an invalid index can cause an error or produce an undefined value, depending on the language.

Takeaway: Use loops for repeated work, functions for coherent reusable behavior, and arrays when data is naturally ordered and accessed by position.

Modeling Data with Objects and Classes

Programs often need to model entities that have both information and actions. An object groups related data and operations. Its data may be called properties, fields, or attributes, and its operations are methods. For example, a student object could contain a name, a score, and a Boolean indicating whether the student passed. A bank-account object might contain an account number and balance along with deposit and withdraw methods.

A class is a blueprint for creating objects. It describes the state and behavior that its instances should have. Two instances of the same class share the class's design but can contain different state. For example, a Counter class might initialize a value, provide an increment method that adds $1$, and provide a method that returns the current value.

Inheritance allows a subclass to reuse and specialize an existing superclass. If Bicycle extends Vehicle, it can inherit general vehicle behavior and override a move method with bicycle-specific behavior. This supports polymorphism: code can work with a general type while the actual object determines which overridden method runs.

Inheritance should represent a genuine “is-a” relationship, such as a bicycle being a vehicle. When one object merely contains or uses another, the relationship is “has-a,” and composition is often a better design. Choosing between inheritance and composition helps keep responsibilities and dependencies understandable.

Takeaway: Use objects to group state and behavior, classes to define shared structure, and inheritance only when the relationship between types is conceptually sound.

Testing, Errors, and Improvement

A program is not complete merely because it starts running. Testing compares actual behavior with expected behavior across several categories of input:

• Normal cases represent typical use.

• Boundary cases exercise the smallest, largest, empty, or otherwise limiting valid inputs.

• Invalid cases check how the program responds to missing, malformed, or out-of-range data.

When a result is wrong, trace the program by recording important variable values after major statements. A trace table can show where actual behavior first diverges from the expected behavior. Then isolate the error by reducing the failure to the smallest input that still demonstrates it and examining the relevant function, condition, loop, or data structure.

Common error categories are:

• A syntax error violates the grammar of the programming language.

• A runtime error occurs while the program executes, such as invalid indexing or division by zero.

• A logic error allows the program to run but causes an incorrect result or behavior.

A disciplined cycle of understanding, designing, implementing, testing, and revising is more reliable than making random changes. Good names, small functions, clear responsibilities, representative examples, and deliberate edge-case checks make both debugging and future maintenance easier.

Takeaway: Use expected results to guide tests, traces to locate divergence, and small reproducible failures to make debugging systematic.