The Comment
The code was a function that processed a list of user records. It was correct, well-tested, and within the style of the codebase. The comment was: 'What happens when this list is empty?'
I'd handled the case. There was a check at the top. But the question made me look at the function from a different angle — not 'does this work?' but 'does this communicate clearly what happens in every state?' The empty list was handled, but the handling was buried three levels deep in a conditional. Someone reading the function would have to trace through the logic to find it.
The Shift
I rewrote the function. The empty case became explicit at the top — early return with a clear comment. Every state the function could be in was now visible from a quick scan. The code wasn't functionally different. It was dramatically easier to reason about.
The question 'what happens in every state?' became part of how I write code, not how I review it. I ask it before submitting a PR now. Often I find the same issue the senior engineer found — not that the state is unhandled, but that the handling is invisible.
Key takeaways
- Ask 'what happens in every state?' before submitting — not just 'does it work for the happy path?' but what happens on empty input, null values, concurrent calls
- Make edge case handling visible — an early return for the edge case is more readable than the same logic embedded in nested conditionals
- Code review questions phrased as questions ('What happens when...?') are more effective than corrections — they prompt the author to reason, not just fix
Conclusion
Six words. The best code review feedback I've ever received. Good reviewers don't just find bugs — they ask questions that change how you think. This one question became a permanent part of how I write code.
Enjoyed this article?
Vivek Kumar Singh
Technical Expert · Full Stack Cloud Engineer · Tokyo, Japan
