We often hear developers glorify “short code.” The common belief is: fewer lines = better code. But in reality, short code does not always mean good code. In fact, sometimes 100 lines of code can be far better than 2 lines of code.
Let’s understand this with a simple example:
The 9 Balls Puzzle
Imagine you have 9 balls, where 8 weigh the same and 1 is heavier. Your goal is to find the heavy ball using the minimum number of weighings.
The optimal solution requires just 2 weighings:
Divide the balls into 3 groups of 3.
Compare two groups. Then compare 2 balls from the heavier group.
In real life, this logic is simple when explained step by step.
But imagine if someone compressed the entire logic into two ultra-clever lines of code. Sure, it might run. But will the next developer (or even your future self) be able to read it, debug it, or extend it easily? Probably not.
The Illusion of Fewer Lines
2 lines of code: might look “smart” but can hide the actual thought process. It’s like solving the 9 balls puzzle by blurting out the answer without showing how you reached it. Impressive at first glance, but impossible to follow later.
100 lines of code: may seem long, but if written with clarity, comments, and step-by-step logic, anyone can trace the reasoning. Just like the step-by-step weighing process, it makes the solution transparent.
Readability > Brevity
Code is read far more often than it is written. When debugging at 3 a.m., you’d much rather have 100 clear lines than 2 “magical” ones.
Short code is not always efficient code. Efficient code is code that is easy to understand, maintain, and extend.
In other words:
👉 100 lines that anyone can understand are better than 2 lines that only you understand.
Top comments (0)