UPI Study › Courses › C++ Programming › Free lessons › Lesson 1.3 Free with a free account
Logical Thinking and Code Structure
C++ Programming · Chapter 1: Foundations of ProgrammingSection 1.3 · lesson 3 of 84video coming soon
← Five Core Ingredients Every Program SharesNext lesson: Sketching the Logic First →
In this lesson
Code is where finished thinking gets written down.
- Split a vague problem into solvable parts
- Separate forced order from free order
- Find the assumptions a machine can't supply
- See how a plan's shape becomes a program's shape
Transcript
Everything said in the video, section by section (1,657 words). Read along, or search it.
Opening Example
The Coffee Request Nobody Spelled Out
Ask a colleague to grab you a coffee on their way in, and the request works. They know which shop is on the way, and that you take it with milk. They know not to wait outside a closed shop, and where to leave it if you're away. None of that was said. A computer supplies none of it. It runs what you wrote, in the order you wrote it, and never wonders whether that's what you meant.
Core Idea
Why Starting Out Feels Hard
That's why programming feels hard at the start. The vocabulary of a language is a few dozen words. The hard part is a plan so complete and unambiguous, that a machine with no judgment can carry it out. And here's the useful discovery: the plan and the program end up with the same shape. Parts of your thinking become blocks, decisions become branches, and repetitions become loops. If the thinking is muddled, the code inherits the muddle. If it's clean, the code is usually short.
Lesson Roadmap
Three Habits of Thought
This lesson builds three habits of thought: decomposition, ordering, and precision. Then we'll see how the shape of a plan becomes the shape of a program.
Decomposition
Splitting the Monthly Statement Task
Nobody solves a large problem. People solve small problems, and assemble the answers. Decomposition is splitting a task into parts small enough to understand, solve and check on their own. Take a request written the way requests actually arrive: email every customer a monthly statement of what they spent. As one sentence, there's no obvious first move. Broken apart, it becomes three jobs: gather the records, work out the totals, and send the message. And each of those splits again. Gathering means finding the customers, pulling their purchases, and keeping only last month's. Totals mean adding up, applying refunds, and rounding to money. Sending means filling in the wording, sending to each address, and recording it.
Why It Matters
Independent Parts Make Big Programs Possible
Now you can work on pulling purchases without knowing how the message will be worded, and fix a refund mistake without disturbing anything else. That independence is the whole point. It's what makes a large program possible for one person to write.
Split Quality
Four Tests for a Good Split
Not every split helps. Parts can overlap, leave gaps, or be too big or too small. Four quick tests catch most of this. One job: can you describe the part in one sentence, with no and? Pull the purchases and email them is two jobs, bolted together. Clear edges: what exactly goes in, and what comes out? Tidy up the data fails, because nobody said what it produces. Checkable alone: could you confirm it's right without running everything else? Handle the customer can only be judged at the very end. And covers the whole: if every part works, is the request finished? A split with no step deciding which month counts leaves a gap, that surfaces late, as wrong numbers. A practical rule: keep splitting until you could explain each part out loud, in about a sentence. If you can't, you don't understand it well enough to write it yet.
Ordering
Forced Orders and Circular Dependencies
Once the parts exist, they have to be arranged. Some orders are forced by reality, and some are yours to choose. A step depends on another when it needs something the earlier step produces. You can't add up purchases before fetching them. Other steps are independent. Gathering one customer's records has nothing to do with another's, so they can happen in any order. If two steps each need something the other produces, that's a circular dependency, and no valid order exists. That's not a scheduling problem. It means the split is wrong, and one part must be broken up further.
Common Mistake
Writing Steps as They Occur to You
The mistake this prevents is common. Beginners write steps in the order they occurred to them, which is the order a person would describe the task. Send everyone their total, and the totals come from last month's purchases, is a perfectly clear sentence, and a completely backwards program.
Dependency Table
Needs and Leaves Behind for Each Step
Writing dependencies down before coding is worth the two minutes it takes. For each step: what it needs before it can start, and what it leaves behind. Finding the customers needs nothing, and leaves a list. Pulling purchases needs that list. Adding up totals needs the purchases. Loading the message wording needs nothing at all, so it can run alongside the whole totaling chain. And sending the message needs both the totals and the template, so it comes last. Any step with an empty needs column can go first. You've found your starting points, and the order writes itself.
Precision
The Literal Reader Test
Human instructions are compressed: the speaker leaves out everything the listener can reconstruct. Writing for a computer means putting all of it back. A useful discipline is the literal reader test. Read your own instruction as someone determined to obey the words exactly, and equally determined not to guess. Every question that reader could reasonably ask is a decision you haven't made yet.
Worked Examples
Turning Vague Instructions into Precise Ones
Sort the names. Alphabetically? Rising or falling? By first or last name? Precisely: rising by last name, then first name, capitals treated as equal, and identical names kept in arrival order. Find the average spend. What about customers with no purchases, and refunds? Precisely: total spend over customers who bought, refunds subtracted, two decimals, and zero if nobody bought. Charge a fee after the due date. Does the due date itself count? Weekends? Precisely: once, on the first calendar day strictly after, weekends included, at one minute past midnight, local time.
Edge Cases
Four Questions for the Edges
The middle of a problem is rarely where instructions fail. Failures cluster at the edges, the situations at the boundary of what you were picturing. Four questions find most of them. What if there are none? An empty list. The average of nothing has no answer, so you must supply one. What if there's exactly one? A plan that compares each item to the next has nothing to compare. What happens exactly at the boundary? If the rule says over 500 rupees, what happens at precisely 500? Half of all rule disputes live on that one line. And what if something is duplicated, missing or malformed? Two customers with the same name, a purchase with no amount, a date typed as text.
Quick Check
Who Is in Delhi and Mumbai?
Quick check. A literal reader is told: list the customers in Delhi and Mumbai. Who ends up on the list? Pause, and predict. Read strictly, only customers in both cities at once, which is usually nobody. In English, and meant either city. The machine reads the words, not the intent.
Common Pitfalls
Everyday Shortcuts That Become Defects
Everyday reasoning isn't sloppy. It's efficient, because it's aimed at another person. Aimed at a machine, the same shortcuts turn into defects. Assumed context: print the summary. Which summary? The listener knew from an earlier conversation, but nothing carries that into the program. Hidden default: add the tax. A person applies the rate they know. The machine must be told the number. Ambiguous connective: the Delhi and Mumbai list you just saw. Vague quantity: if the file is large, split it. Large is a judgment, not a measurement. And unstated exception: every customer gets a statement. People hear every, with sensible exceptions attached. The machine hears every.
Self Test
The Hostile but Literal Reader
So here's a test for your own writing. Could a hostile but literal reader obey these words, and still produce something you'd call wrong? If so, the instruction isn't finished.
Code Structure
Plan Shapes Become Program Shapes
Here's where the thinking pays off. Programs have only a handful of structural shapes, and each one expresses a shape already in your reasoning. When your plan says first, then, finally, that's a sequence. Decide whether the order is genuinely forced. If, otherwise, unless: that's a choice. Decide what happens in the case you didn't mention. There's always one. For each, until, keep doing: that's repetition. Decide what's repeated over, and what makes it stop. And, that whole thing counts as one step, is grouping. Decide where it begins and ends, and what it hands back.
Readability
Indentation as a Picture of Reasoning
In code, steps in the same group sit at the same indentation, and steps inside a choice or a repetition move one level to the right. That indentation is a picture of your reasoning. Readable code is code whose visible shape matches the idea behind it. Tangled code usually flattened a clean plan into one long run, or never had a plan at all.
Worked Example
Dinner Bill: Decompose and Order
Here's a real request, through all three habits: work out what each person owes for a shared dinner bill. First, decompose. Record what each person ordered. Work out shares of the shared items. Apply service charge and tax. Round, and settle the leftover. Report. Then order. Shares come after recording, tax after a subtotal, and rounding after tax, or the numbers won't add up to the printed total. Recording one person versus another is free: any order works.
Worked Example
Dinner Bill: Making Every Rule Exact
Finally, precision. Are shared items divided equally? Yes, among everyone present. Is the service charge on food only? Yes, and tax applies to food plus service. What if someone ordered nothing? They pay an equal share of shared items, and nothing else. And if rounding leaves a one-paisa gap, the largest share absorbs it, so the totals always match the bill. Every one of those answers is a line of code you'd otherwise have written wrong. And not one of them needed a programming language.
Key Takeaways
From Clear Parts to Code Structure
To summarize. Break the problem into parts that each do one job, small enough to explain in a sentence. Work out which parts depend on which. An empty needs column is a starting point, and a cycle means the split is wrong. State every part so exactly that a reader with no judgment could carry it out, especially at the edges: none, one, the boundary, and bad data. Do that, and the program's structure of sequence, choice, repetition and grouping is already in the plan, waiting to be written down.
Think About It
The 1,000 Rupee Delivery Fee Rule
Here's something to think about. A rule reads: waive the delivery fee for orders over 1,000 rupees. Which edge case is certain to cause an argument? And how would you restate the rule, so nobody could argue?
About C++ Programming at UPI Study
C++ Programming (Computer Science 242) is a self-paced online course of 84 video lessons in 11 chapters, from your first program to decisions, loops, arrays, functions, classes, files, pointers and inheritance. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus Every course with PRO →
Why take it here
Why students take C++ Programming with UPI Study
Where the credit goes
Universities that work with NCCRS
C++ Programming carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Logical Thinking and Code Structure
How do I break a vague programming problem into smaller parts?
How do I know which steps must come first and which can go in any order?
What does it mean that a computer can't supply assumptions, and how do I fix vague instructions?
How does a plan's structure turn into the structure of a C++ program?
About the C++ Programming course
How many college credits is C++ Programming?
How much does C++ Programming cost and what is included?
Which universities accept UPI Study credits?
How long does C++ Programming take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in C++ Programming.
84 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →