Programming Principles: Short readable function -> better Debuging

The longer you spend writing or reading code, the more you’ll realize how true this is.
A long function isn’t readable — even if you use perfect variable names and have a clear logic flow.
A long class isn’t readable either — even if you apply every best practice you know.

Actually, the longer the code gets, the harder it becomes to apply any best practice in the first place.

Easy to apply and help to apply the other principles

Keeping your functions and classes short doesn’t just make your code look clean — it also helps you apply other important programming principles without even trying, like:

• DRY (Don’t Repeat Yourself)
  When your functions are small and focused, you naturally start noticing repeated logic.
  Instead of copy-pasting code, you’ll think, “wait, I already wrote something that does this.”
  Refactoring becomes easier because your building blocks are small and reusable.
  In long messy functions, repetition hides easily — you could be doing the same thing three times in different places without realizing it.

• Single Responsibility
  This one fits perfectly with short functions.
  A function that’s short usually does one job.
  When it starts doing two or three things, you’ll feel it — the size grows, the naming gets harder, and debugging becomes confusing.
  If your function name sounds like a sentence (“fetchAndProcessAndSaveData”), that’s your sign to split it.

• Code for Humans First, Machines Second
  The compiler doesn’t care how your code looks — but humans do.
  Machines will run a 200-line function just fine, but humans will suffer trying to read it.
  Writing short, clear functions means you respect the next person who’ll read your code — and most of the time, that next person will be you in a few months.
  Code should tell a story, and short functions keep the story easy to follow.

I like this rule because it’s simple and easy to catch.
Even a beginner programmer can look at your code and instantly tell you, “This function is too long.”
Compare that to something like the Open/Closed Principle, where you have to read the whole class and think about multiple edge cases just to spot the issue.

How short should code be?

There’s no strict rule. It depends on the language, but generally, functions between 10 to 20 lines are a good range — maybe closer to 20 for front-end code.

Each line should do one clear thing.
For example, in .NET, it’s tempting to chain multiple actions in one line, like this:

var result = this.data.GetAll().Where(x => x > en.age).SortBy(x => x.CreationDate).Limit(10);

This isn’t a “line” in the readable sense — it’s a wall of logic.
Instead, it should be written like this:

var result = this.data.GetAll()
                      .Where(x => x > en.age)
                      .SortBy(x => x.CreationDate)
                      .Limit(10);

Now each part is easy to scan, easy to debug, and clear in intention.
You instantly know what happens in each step without mental parsing.

Another small but useful thing — limit each line’s maximum number of characters.
Once you start scrolling horizontally, readability is gone.

Why this matters for debugging

When your code is short and focused, debugging becomes faster.
You can isolate issues easily because your functions do one thing — and only one thing.
You don’t have to jump between a giant function trying to trace where something went wrong.

In real projects, this rule saves time, reduces bugs, and helps other developers (and your future self) understand what’s going on.
Long code might “work,” but short code lives longer.