{"title":"How to Approach Logic Problems","description":null,"content":"Knowing a language's syntax is one skill. Turning a problem written in plain English into working code is a different one. This chapter gives you a repeatable process for reading a worded problem, planning a solution, and turning that plan into code that runs correctly.\n\nThis chapter covers:\n\n- A five-step process to go from a worded problem to working code\n- How to choose between a `for` loop and a `while` loop\n- How to translate English phrases into boolean conditions\n- A practical debugging mindset for when your code is wrong\n- When to extract logic into a helper function and when to keep it inline\n\n---\n\n# A Repeatable Process: Read, Restate, Trace, Code, Test\n\nSimple coding problems become easier when you stop writing code immediately. Jumping straight to the keyboard leads to off-by-one errors, wrong conditions, and code that solves the wrong problem. A short, repeatable process prevents those mistakes.\n\nThe process has five steps: read, restate, trace, code, and test. The diagram below shows how they connect.\n\n\n```mermaid\nflowchart LR\n A[Read]:::primary --> B[Restate]:::teal\n B --> C[Trace]:::orange\n C --> D[Code]:::green\n D --> E[Test]:::primary\n E -->|edge case fails| A\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nLet us apply all five steps to one small problem: find the sum of all even numbers from 1 to `n`.\n\n## Step 1: Read the Problem Carefully\n\nRead the full problem before deciding anything. Note the input, the output, and any limits. For our example, the input is a single number `n` and the output is the sum. The word \"even\" matters, because odd numbers are excluded. The range \"from 1 to n\" is inclusive on both ends.\n\nMissing one word like \"even\" or \"inclusive\" sends you down the wrong path before the first line.\n\n## Step 2: Restate It in Your Own Words\n\nSay the problem back to yourself in plain language. For our example: \"Walk through every number from 1 up to and including `n`. Whenever a number divides evenly by 2, add it to a running total. Return that total.\"\n\nIf you cannot restate it cleanly, you do not understand it well enough to solve it yet. Go back to step 1.\n\n## Step 3: Trace It by Hand on a Small Input\n\nPick a small input and work the answer out on paper. For `n = 6`, the even numbers are 2, 4, and 6, summing to 12. The table below shows the running total at each step.\n\n\n| Number | Even? | Running total |\n| --- | --- | --- |\n| 1 | no | 0 |\n| 2 | yes | 2 |\n| 3 | no | 2 |\n| 4 | yes | 6 |\n| 5 | no | 6 |\n| 6 | yes | 12 |\n\n\nYou now have an expected answer of 12 for `n = 6` to check your code against.\n\n## Step 4: Write the Code\n\nThe hand trace maps directly to code: a running total starting at 0, a loop over every number from 1 to `n`, an evenness check, and an addition when it passes.\n\n\n```java\nint sumOfEvens(int n) {\n int total = 0;\n for (int i = 1; i <= n; i++) {\n if (i % 2 == 0) {\n total += i;\n }\n }\n return total;\n}\n```\n\n\nEach part of the code lines up with the trace. The variable `total` is the running total column, the loop walks the number column, and the `if` check is the \"Even?\" column. Once the trace is done, writing the code is mechanical.\n\n## Step 5: Test Against Edge Cases\n\nRun your code on the input you traced by hand. For `n = 6`, it should return 12. If it does, try the inputs that sit at the boundaries of the problem:\n\n- `n = 1`: no even numbers in range, so the answer is 0.\n- `n = 2`: the only even number is 2, so the answer is 2.\n- `n = 0`: the loop never runs, so the answer is 0.\n\nIf any of these fail, return to the start of the loop. Re-read the problem, fix your understanding, and trace again. The arrow from \"Test\" back to \"Read\" in the diagram is the part beginners skip, and it is where most bugs get caught.\n\n---\n\n# Picking the Right Loop: for vs while\n\nAlmost every warmup problem involves repetition. The choice of loop comes down to one question: do you know how many times the loop will run before it starts?\n\nWhen the iteration count is fixed and known up front, use a `for` loop. Counting from 1 to `n`, visiting every element of an array, or repeating an action exactly `k` times all give you the count in advance.\n\nWhen you loop until some condition becomes true and cannot predict how many steps that takes, use a `while` loop. Peeling digits off a number one at a time until it reaches 0 is a clear example, since you do not know how many digits the number has until you start removing them.\n\n\n| | `for` loop | `while` loop |\n| --- | --- | --- |\n| Use when | Iteration count is known up front | You loop until a condition is met |\n| Driven by | A counter that increments | A condition that changes inside the loop |\n| Typical examples | Count 1 to n, walk an array | Process digits of a number, read until end |\n\n\nHere is a counting `for` loop that prints the numbers 1 through 5. The count is known before the loop begins.\n\n\n```java\nfor (int i = 1; i <= 5; i++) {\n System.out.println(i);\n}\n```\n\n\nHere is a condition-driven `while` loop that removes digits from a number until nothing is left. The number `num` starts at 472, and each pass strips off its last digit. The loop stops when `num` reaches 0, but the code does not know in advance that this takes three passes.\n\n\n```java\nint num = 472;\nwhile (num > 0) {\n int lastDigit = num % 10;\n System.out.println(lastDigit);\n num = num / 10;\n}\n```\n\n\nThis prints 2, then 7, then 4. The modulo operator `%` pulls off the last digit, and integer division by 10 shifts the rest right. A `for` loop would be awkward here because the iteration count depends on how many digits the input has.\n\n---\n\n# Translating Words into Conditions\n\nA worded problem often hides a boolean condition inside an English phrase. Spotting these phrases and converting them into code is a core part of turning problems into solutions. The table below maps common phrases to the conditions they represent.\n\n\n| English phrase | Code condition |\n| --- | --- |\n| `x` is even | `x % 2 == 0` |\n| `x` is odd | `x % 2 != 0` |\n| `x` is divisible by `d` | `x % d == 0` |\n| `x` is between `a` and `b` (inclusive) | `x >= a && x <= b` |\n| `x` is at least `a` | `x >= a` |\n| `x` is at most `b` | `x <= b` |\n| `x` is positive | `x > 0` |\n| `x` and `y` are both positive | `x > 0 && y > 0` |\n| `x` is zero or negative | `x <= 0` |\n\n\nA few deserve a closer look. \"Divisible by\" almost always means the remainder is 0, which the modulo operator gives directly. The word \"inclusive\" controls whether you use `<` or `<=`. \"Between a and b\" usually means inclusive on both ends, so it becomes two comparisons joined with `&&`. When two things must both hold, combine them with `&&` (and); when either one is enough, use `||` (or).\n\nOnce you can translate a phrase like \"count the numbers between 10 and 50 that are divisible by 7\" into `n >= 10 && n <= 50 && n % 7 == 0`, the rest of the problem is a loop around that condition.\n\n---\n\n# A Debugging Mindset: Print, Trace, Dry-Run\n\nCode rarely works on the first try, so finding why it is wrong matters as much as writing it. Three techniques do most of the work.\n\n**Add print statements to see intermediate values.** A wrong final number tells you nothing about where it went wrong. Print the variables inside the loop to watch how they change.\n\n\n```java\nint total = 0;\nfor (int i = 1; i <= n; i++) {\n if (i % 2 == 0) {\n total += i;\n }\n System.out.println(\"i=\" + i + \" total=\" + total);\n}\n```\n\n\nRunning this shows the running total after every step. If the printed values stop matching your hand trace at, say, `i = 4`, the bug is in how step 4 is handled. The print narrows the search from the whole program to a single line.\n\n**Dry-run on paper.** Pick a small input and execute the code by hand, line by line, writing down each variable as it changes. This is the trace from step 3, now applied to the exact code you wrote rather than the plan. A dry-run catches bugs prints cannot, because it forces you to read what the code does instead of what you meant it to do.\n\n**Check the boundaries.** Most bugs hide at the edges of the input range, not the middle. Test these cases deliberately:\n\n- Zero: does the loop behave when the input is 0?\n- One: the smallest non-trivial case often exposes off-by-one errors.\n- Negative numbers: does the code assume the input is positive?\n- Empty input: an empty array or a count of 0 should not crash.\n\nA program that handles `n = 100` correctly can still fail on `n = 0` or `n = 1`. Testing the boundaries first finds those failures fast.\n\n---\n\n# Helper Function vs Inline Code\n\nAs problems grow, you face a choice: keep all the logic in one block, or pull a piece into a small helper function. The answer depends on whether the logic is reused and whether it forms a self-contained sub-step.\n\nPull logic into a helper function when:\n\n- The same logic is needed in more than one place. Writing it once and calling it twice avoids duplicated code that can drift out of sync.\n- The logic is a self-contained sub-step with a clear name, such as \"count the digits of a number\" or \"check whether a number is prime.\" A named helper makes the main code read like a description of the steps.\n\nKeep logic inline when:\n\n- It is used only once and is short enough to read at a glance.\n- Extracting it would add a function call without making the code clearer.\n\nConsider a problem that needs a number's digit count in two places. The digit-counting logic is both reusable and a clean sub-step, so it belongs in a helper.\n\n\n```java\nint countDigits(int num) {\n if (num == 0) return 1;\n int count = 0;\n while (num > 0) {\n count++;\n num = num / 10;\n }\n return count;\n}\n```\n\n\nWith this helper in place, the main code calls `countDigits(472)` and gets 3 without restating the loop. If the problem only counted digits once, as a small part of a larger loop, leaving the `while` loop inline would be fine, since extracting it would add a layer without paying for itself.\n\nA practical rule: write the logic inline first. When you find yourself copying it to a second spot, or when a block grows large enough that a name would explain it better than the code does, move it into a helper.\n\n---\n\n# Where This Leads\n\nYou now have a process for reading a worded problem, a way to choose the right loop, a method for turning English into conditions, a debugging routine, and a sense of when to reach for a helper. These tools apply on every problem that follows.\n\nThe next set of problems puts each idea into practice on small, focused tasks: printing sequences of numbers, summing values across a range, and working with the individual digits of an integer. Each one is small enough to trace by hand and solve in a single loop, a good place to build the habits from this chapter before the problems grow.","pageType":"dsa"}

How to Approach Logic Problems

Get Premium