Clean code: what it is and why it’s important

Code. Write it well and you’ve got a gorgeous software or an app that works well and is easy to maintain. Write it poorly and you might still have a gorgeous design, but we can bet bugs start popping up right and left. Our very own Software Engineer Paulo Poffal shares why clean code matters.

We’re all kind of geeks around here at PoaTek, so we get why writing good code is such a big part of great software and mobile apps. But if you tend to geek out about other stuff, say financial reports or marketing trends, you may think a line of code is just that: a line of code. It turns out, however, that not all code is created equal. PoaTek Software Engineer Paulo Poffal shares just why clean code is important.

What is it?

Clean code is code that other developers can easily read, understand, and add to. It’s easy to write code that just the machine will understand or code that just you understand, but that proves problematic in the long run.

“It’s basically code that other developers can understand,” Paulo said. “That’s the basic principle of clean code. Because you don’t write code for a machine to understand, you don’t write for yourself, you write for other developers. Other people will need to read your code and change your code and fix bugs and add more features.”

Here are a few principles Paulo gives that should guide how code is written:

Clean code is expressive.

This means that another developer can look at a piece of code and know exactly what it’s about. The class names, the structure – it should all make sense. Good code is self-documented code. In other words, your code shouldn’t need pages and pages of documentation to explain it. It should explain itself.

“Clean code must be expressive,” Paulo said. “You should be able to read it the first time you see the code [and know] what it is about. You may not understand everything, but you already know what that part of the code is about – the names, the class names, the structure must be expressive.”

Clean code is simple.

There are a few rules that good developers live by to keep code from turning into some gargantuan maze of functions and classes. The KISS principle, or Keep It Simple Stupid, for starters – systems work best when they are founded on simplicity, not complexity. This idea should be at the basis of any good code design.

Single responsibility is another rule. Each class or function should only have one responsibility. For instance, if you’re building an ecommerce marketplace, there should be one class for gathering customer data, one class for collecting credit card information, and so on. If a class is doing multiple things, it’s going to get messy fast.

Another is to not repeat yourself. Why reinvent the wheel? But coders do this all the time. Say they’re writing a program that needs to create users in multiple places. Instead of creating a function that does that everywhere it supposed to happen in the code, they copy and paste their code throughout the whole program. Again, this gets messy really fast.

Clean code is also maintainable.

When you don’t take the time to write good code, good luck updating it, testing it, and adding new features down the road. Poorly written code is confusing and hard to change later without creating more bugs. Good code, however, is the opposite – because it’s expressive and simple, it’s easy for the original developer and for others to update and fix as time goes on.

Why developers don’t do it

So all of this makes sense theoretically, right? It looks good on paper, but in practice, plenty of developers out there just don’t do it. Why not? For starters, some of them just may not have the knowledge base. Take a junior developer, for instance. If they’ve only worked on small projects or with more senior developers who aren’t motivated themselves to write clean code, they’ll never learn how to do it for themselves.

Another obstacle is lack of motivation. Say you’re working with some developer from an outsourcing platform for a few bucks an hour. For a few bucks an hour, that person is going to lack motivation to do a good job. You may get a website out of the deal, but give it a few months and you’ll start to see bugs that could have been avoided.

A final obstacle is lack of time. Let’s face it, writing bad code takes a whole lot less time because it’s not as top heavy. Clean code takes a lot of time and careful thought to plan for. Jumping right  in and writing with no thought for the eventual user, other developers, or the overall design is much easier. But when developers are faced with tight deadlines, poorly written code might be their only option. That’s why it’s important for managers to offer generous deadlines so the development team can take its time to create really functional code.

Why it’s important

Like we established before, poorly written code may be faster in the short term, but in a few months, you’ll be glad you made the investment in clean code. When you’ve taken time and effort into your code’s design, adding new features, fixing bugs, and collaborating with other developers will be much easier.

How to do it

Here at PoaTek, we always have someone else review our code before it’s finished. On-going team discussion helps us fix bugs quickly, grow our knowledge, and share new ideas.

“We have something called a Pull Request that everyone does – this is something that is done by all the developers in the market,” Paulo said. “Before you put changes into the code itself, you create a Pull Request to see the difference between the [new code] and the old code. All the other developers from your team review the code and give comments and say I think this should be better, I think this should be different, and you have a discussion between your team. This is also a good way to share knowledge. This is really important because sometimes when you have junior developers, this is a way to help them increase their knowledge and leverage the knowledge of all the members on the team.”

We also practice TDD or test-driven development. Each unit of a project is tested before moving on to the next unit and each change we make to already completed code is tested. The best way to do TDD is to write the test before you write your code. Doing so will help you see what your code needs to achieve and it will help you simplify. Finally, we are continuously refactoring. Just like an author who is never satisfied with their novel, we constantly revisit our code over time to find ways to improve it.

Is your software, website, or mobile app not working for you? Chances are there are some bugs to work out. Contact us about starting a project with us, clean code guaranteed!