Recursion: base case first, cleverness later

Recursion becomes much less mysterious when you ask one question first: when does it stop?

Use this post as a small study note for making better decisions while solving, not as a quick definition dump. Read the idea, pause at the example and try to move one line forward yourself, then use the checklist on a real problem.

The main idea

Write the base case, then describe how each call makes the input smaller or simpler.

The important part is not memorizing the method; it is noticing what calls the method into action. Which expression, diagram, unit, variable, or code behavior made this approach the right one? If you can name that trigger, a similar problem becomes much less stressful.

A short example

Factorial stops at $0$ or $1$; every other call moves one step closer to that base case.

How to approach it step by step

1. Write the givens cleanly and fix units, symbols, or variable names before calculating.
2. Identify the intermediate fact you need before trying to jump directly to the answer.
3. After each line, run a small check: do the units match, is the sign correct, is indentation or scope correct in code?
4. When you get an answer, return to the original question and check that it answers exactly what was asked.

Check while you solve

• Find the base case.
• Find the smaller input.
• Trace one small example, such asfactorial(3).

The common mistake

A recursive function without progress toward a base case is just a loop with a hidden stack.

The practical way to catch this mistake is to check the decision points, not only the final answer. Ask questions like: Why this formula? Why this component? Why this loop condition? That makes the answer stronger in content, not just in arithmetic.