Practical Logic and Structured Programming
Structural Programming Logic
From Lines to Logic
You already know how to write individual lines of code and simple conditional statements. The next step is learning to think like a programmer, which means structuring your thoughts before you even write the first line. The goal isn't just to get the computer to do something, but to do it in a way that's clean, predictable, and easy to manage.
Big, complex problems are rarely solved in one go. Instead, we break them down into smaller, self-contained tasks. Think about building a car. You don't start by welding random pieces of metal together. You have separate teams for the engine, the chassis, and the interior. Each team focuses on one job, does it well, and then all the pieces are assembled. This is the core idea of problem decomposition in programming.
The structured approach allows programmers to break down long and complex tasks into shorter segments.
Before writing code, it helps to map out the logic. A flowchart can be a great tool for this. It visually represents the sequence of actions and decisions in your program. For example, let's sketch out the logic for a simple program that checks if a user's input number is even or odd.
This kind of planning, often done with flowcharts or , ensures your logic is sound before you get bogged down in syntax. It forces you to think about the flow of control and how different parts of your program will interact.
Building with Functions
In programming, our small, self-contained tasks are usually functions. A well-designed program is composed of many small functions, each with a clear purpose. This leads to the Single Responsibility Principle (SRP). SRP states that every function should have responsibility over a single part of the program's functionality. It should do one thing, and do it well.
Why is this important? Imagine a function called processUserData(). If this function fetches data from a database, validates the user's email, and updates their profile picture, it's doing too much. If a bug occurs in the email validation, you have to dig through a large function that also handles database and image logic. It's messy.
A better approach is to have three separate functions: fetchUserFromDB(), validateEmail(), and updateProfilePicture(). Each one is simple, easy to test, and can be reused elsewhere if needed.
# BAD: Violates Single Responsibility Principle
def process_user_data(user_id):
# 1. Fetches data
print(f"Fetching data for user {user_id}...")
# 2. Validates email
print("Validating email...")
# 3. Updates profile
print("Updating profile...")
return True
# GOOD: Follows Single Responsibility Principle
def fetch_user_from_db(user_id):
print(f"Fetching data for user {user_id}...")
return {"id": user_id, "email": "test@example.com"}
def validate_email(email):
print(f"Validating {email}...")
return "@" in email
def update_profile(user_id):
print(f"Updating profile for user {user_id}...")
return True
This modular approach makes your code much easier to debug and maintain.
Managing State and Scope
As you break your code into functions, you need to understand how they handle data. This is where variable scope comes in. A variable's scope determines where in your program it can be accessed.
Variables defined inside a function are local to that function. They are created when the function is called and destroyed when it finishes. They cannot be seen or used by code outside that function. Variables defined outside of any function are global. They can be accessed from anywhere in your script, including inside functions.
While global variables might seem convenient, they can be dangerous. If multiple functions can modify the same global variable, it becomes very difficult to track changes and debug problems. Your program's state becomes unpredictable. It's generally best to limit the use of global variables and instead pass data into functions as arguments.
| Scope | Definition | Accessibility | Best Practice |
|---|---|---|---|
| Local | Declared inside a function | Only within that function | Preferred for most variables. |
| Global | Declared outside all functions | Anywhere in the script | Use sparingly, for constants. |
This leads us to the idea of a pure function. A pure function is a function that, for the same input, will always return the same output and has no observable side effects.
A side effect is any way a function interacts with the outside world beyond returning a value. Examples include modifying a global variable, printing to the console, or writing to a file. Pure functions are like mathematical functions: add(2, 3) will always be 5. It doesn't change anything else in the program.
Code built from pure functions is highly predictable and easy to test. You don't need to worry about the state of the rest of the program to know what the function will do. While not all functions can be pure (you eventually need to interact with the outside world), aiming to make functions pure whenever possible is a hallmark of clean, structured programming.
# A pure function
# - Its return value depends only on its inputs.
# - It has no side effects.
def add(a, b):
return a + b
# An impure function
# It has a side effect: printing to the console.
# Its behavior is not just about its return value.
def add_and_print(a, b):
result = a + b
print(f"The result is: {result}") # Side effect!
return result
By combining problem decomposition, the single responsibility principle, careful scope management, and a preference for pure functions, you can move from simply writing code to architecting robust and logical programs.
What is the primary goal of "problem decomposition" in programming?
You have a function named handleUserLogin that checks the user's password, logs the login attempt to a file, and sends a welcome email. According to the Single Responsibility Principle (SRP), what is the best way to refactor this?
Now you have the tools to structure your programs logically, making them easier to build, debug, and maintain.