DEV Community

loading...

Should I break down my code if it'll only be used once?

JavaScript Joel
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
・2 min read

Camera Broken Down

Should I break down my code if it'll only be used once? This is a question I hear often.

The tl;dr answer is Always break down your code.

Code is not written for the computer, it is written for humans

If we want to write code for computers we would code in machine language. But instead we choose to use high level languages like JavaScript, which are easier for humans to understand.

This is an important key to writing good software. Shift your mentality from writing code for computers to writing code for humans. Knowing the audience of your product (the code), in this case humans, will greatly improve the software you write.

Write your code to be readable

Try to imagine a book with no paragraphs. Pause on this thought and really think about this.

If that idea sounds horrifying and that book sounds tedious to read then imagine that feeling multiplied by ten for a huge function or a massive class that someone has to read.

Don't write a book with no paragraphs or chapters, break your code into readable chunks!

But this code is only used once

That code may be used only once now. But if you don't break your code down, you are guaranteeing that code can never be reused in the future.

Nobody can predict the future. Give your code the opportunity to be reused later. That function you break out now could become a function you reuse tomorrow.

Maybe all that code you are writing today could have been avoided if your code was written to be reusable yesterday. Reflect on that.

Think about unit tests

Your project has no tests so why should you write testable code?

Do you also want to ensure your code can never be tested in the future?

Just because a project has no unit testing today doesn't mean that it won't have tests at some point in the future.

Don't be the guy who's code will be untestable when the unit tests do come. Your name is forever on those commits. And the next developers will definitely git blame you.

Summary

  • Always break down your code.
  • Write code for humans to read. They are your audience, not computers.
  • Give your code opportunity to be reused in the future.
  • Even if your project has no unit tests now, don't prevent your code from being tested in the future.
  • Your name is forever on that commit, you will be judged.

Read more of my functional programming-ish articles.

Pet a cat

Follow me on Twitter @joelnet

Cheers!

Camera Photo by Alexander Andrews

Discussion (1)

Collapse
leoat12 profile image
Leonardo Teteo

I think you cannot be excessive either. I generally create methods based on action, if it is named "update" it means it will update something and everything related to update the entity will be there. Sometimes it is simple line, other it can span through 20~40 lines, depending on the business logic. Everything is related to an action, so I don't think it is necessary to break everything down.
The excess happened in some old code here sometimes, there are a method that calls a method, that calls a method, some of them are 3~4 lines of code! If you think it is more readable, I respectfully disagree. You have to jump around the code and get lost in the process.

Forem Open with the Forem app