Why 100 Lines of Code Can Be Better Than 2 Lines

Have you ever asked yourself, “Why write 100 lines of code when I can do the same in just 2?”

It may sound smart to keep your code as short as possible. But here's the truth: short code isn’t always good code.

Let’s walk through a simple, relatable example, and then a real coding scenario, to show why writing more lines can actually be a better choice, especially when it comes to understanding, debugging, and working with a team.

---

☕ Let’s Start with Tea (Chai): A Simple Example

Imagine someone asks you how to make chai. You could just say:

“Put everything in a pan and cook.”

Technically, that might work—but will the chai taste right? Probably not.

Now imagine you get this version instead:

1. Boil water

2. Add tea leaves

3. Let it simmer

4. Add sugar

5. Add milk

6. Boil again

7. Strain and serve

Which one makes better chai? Obviously the second one. It has clear steps, and anyone can follow it.

This is exactly how coding works too. Just like making chai, programming needs proper steps. If you try to stuff everything into 1 or 2 lines, the final result might run—but it won't be clear, and it's hard to understand or fix later.

---

🎯 The 9 Balls Problem: Real Example

You have 9 balls, where 8 weigh the same and 1 is heavier. Your task is to find the heavy ball using the least number of comparisons.

In class, one student wrote the solution in just 2 lines. Another wrote it in around 100 lines.

Which one do you think was better?

• The 2-line version looked fast but was confusing.

• The 100-line version was clear, easy to read, and explained every step.

---

❌ Short Code Example (Hard to Understand)

Here’s an example of short code that loops through the array to find the heavy ball:

int ball[9] = {1, 1, 1, 1, 1, 1, 1, 2, 1}; 
int wt = ball[0]; 
int heavyindex = 0;

for (int i = 1; i < 9; i++) {
    if (ball[i] > wt) {
        wt = ball[i]; 
        heavyindex = i;    
    }
}

cout << "Heavy ball is at index: " << heavyindex << endl;

❗ What's Wrong with This?

Yes, it gives the correct answer. But:

• It checks all 9 balls, even though you can solve this problem with just 2 comparisons using logic.

• It ignores the puzzle’s main goal: minimizing the number of checks (just like using a weighing scale only twice).

• It’s short, but it misses the thinking and strategy behind the problem.

So even though the code is small, it’s not the smartest way to solve it.

---

✅ Clear and Correct Code Example (Easy to Understand)

Let’s now write a more structured version using proper groups and logical flow:

int a[9] = {1, 1, 1, 1, 1, 1, 1, 2, 1}; // One heavier ball
int groupA = a[0] + a[1] + a[2];
int groupB = a[3] + a[4] + a[5];
int groupC = a[6] + a[7] + a[8];

int heavyIndex;

if (groupA == groupB) {
    // Heavy ball is in group C: a[6], a[7], or a[8]
    if (a[6] == a[7]) {
        heavyIndex = 8;
    } else if (a[6] > a[7]) {
        heavyIndex = 6;
    } else {
        heavyIndex = 7;
    }
} else if (groupA > groupB) {
    // Heavy ball is in group A
    if (a[0] == a[1]) {
        heavyIndex = 2;
    } else if (a[0] > a[1]) {
        heavyIndex = 0;
    } else {
        heavyIndex = 1;
    }
} else {
    // Heavy ball is in group B
    if (a[3] == a[4]) {
        heavyIndex = 5;
    } else if (a[3] > a[4]) {
        heavyIndex = 3;
    } else {
        heavyIndex = 4;
    }
}

cout << "Heavy ball is at index: " << heavyIndex << endl;

🎯 Why This Is Better:

• Uses only 2 comparisons, like a balance scale

• Follows logic, not just brute-force looping

• Easier to modify, scale, and explain

• Much more aligned with how such puzzles are supposed to be solved

---

✅ Why Writing More Lines Makes Sense

🧩 1. It's More Readable

You (or someone else) can understand what’s happening line by line—even after months.

🔍 2. Easier to Debug

If something breaks, you’ll know exactly where to look.

🤝 3. Team-Friendly

In a team setting, everyone needs to understand your code—not just you.

---

⏱️ But Isn’t Short Code Faster?

Not always. Here’s what actually affects speed:

• Background processes

• Input/output size

• Network or system load

• Hardware performance

A smart 100-line code can run faster than a badly written 2-line shortcut. So, don’t let line count fool you.

---

⚖️ When Short Code Is Okay

Sure, for things like:

• One-time scripts

• Simple functions

• Quick automation

Short code can work. But in larger projects or logic-based problems, you want your code to be clear, organized, and maintainable.

---

🧠 Conclusion: Write Code That Talks

Think of your code like a conversation.

Would you rather someone said:
“Eat food.”
Or:
“Here’s your plate, there’s rice, dal, roti—enjoy!”

Clear communication wins. Every. Time.

So the next time you're tempted to squash your logic into two lines, ask yourself:

“Will I (or anyone else) understand this code tomorrow?”

If the answer is no, go for clarity—even if it takes 100 lines.