A recursive count of comments in a thread returns 0 for every thread — what base-case mistake explains it?

## Termination and correctness are separate obligations The first thing to say out loud is what the symptom rules out. The function returns, so nothing is wrong with termination: there is a base case, the subtree shrinks on every descent, and the recursion unwinds. What is wrong is the *value* the base case returns. Reviewers who have been trained to check that a base case exists often stop the moment they see one, and this is the family of bug that slips past them. ## The base case is the smallest instance of the same promise A recursive function has a contract — here, "return the number of comments in this subtree, including the node I was given". The recursive branch is written against that contract: it trusts each child call to return the child's whole subtree count. The base case must satisfy **the same** contract at its smallest input. A comment with no replies is a subtree of exactly one comment, so the correct answer at the base is 1, not 0. Returning 0 says "this subtree is empty", which is a different sentence about a different structure. Because every leaf contributes 0 and no internal node adds itself, the error does not merely accumulate — it annihilates. The total is 0 for every input, including a thread with a thousand replies. A bug that produces a plausible-but-low number is arguably worse; this one at least announces itself immediately. ## Half-fixes Changing the base to return 1 and stopping there leaves the function wrong in a quieter way. Consider a root with two childless replies: the leaves now return 1 each, the root sums them to 2, and the true answer is 3. The root never counted itself. Both branches encode the contract, so both branches have to be repaired. This is exactly why the interesting review question is not "is there a base case" but "do the base case and the recursive case say the same thing about the same contract". ## Prefer the degenerate base to the one-step-early base The deeper design point is that the `is-empty(children(node))` guard is unnecessary. Write the general case as "one for this node, plus the sum over children", and a node with no children falls straight out of it: the loop body never executes, and the function returns 1. The contract then lives in exactly one place. A special case that duplicates what the general case already handles is a standing invitation for the two to drift apart — someone later changes the counting rule in the loop and forgets the guard above it. The rule of thumb is to base on the truly degenerate input (nothing left to process) rather than on the input that is one step away from degenerate (no children, one element left, one node remaining), and to add an earlier base case only when the general case genuinely cannot express it. There is one case that still needs its own answer: an entirely absent thread, where there is no root node at all. That is a different input shape — an empty structure rather than a smallest non-empty one — and it needs an explicit answer of 0 at whatever boundary can produce it. ## How to check a base case's value in review A mechanical check that costs seconds: take the function's stated contract, substitute the smallest input, and read off what the contract demands. Then look at what the base case returns. If they differ, the recursion is wrong no matter how elegantly the general case is written. Run the same substitution on the general case with a one-level input and check that the two agree. Most base-case value bugs — returning 0 where 1 is meant, returning an empty accumulator where the identity element is meant, returning the item where a collection containing the item is meant — surface immediately under that test.