If you ask any professional developer, they will tell you that beautiful code is important. But what is beautiful code and why does it matter?

The best way to answer that is to look at an example. Here’s one that comes directly from the inside of a developer’s mind.

An Example of Some Ugly Code

Mindset: you are a developer now and you’re trying to fix a bug in code that manages the checkout process for a shopping cart. Your boss told you that it needs to be fixed urgently, as it is making your business lose sales and customers every minute.

You find the piece of code that takes care of that, and this is what you find, and your thoughts as you read it:

It might probably surprise you (or not) that by line 12 we had already lost our train of thought completely. This code is not readable at all, and while you still went through it from top to bottom, you were not able to find the mistake.

That is generally the problem with “ugly” code – it is hard to read and hard to understand, which translates to “hard to fix” or “hard to extend”. It makes the job of developers difficult by impeding progress on new features, bug fixes, and improvements.

This particular example has several problems. Most glaring, however, is an anti-pattern called “callback hell” – it suffers from several levels of nesting, requiring the reader to maintain several levels of conditional nesting in their head.

And believe me – this example was way too simple to be a real life application. Three levels of nesting and 20 lines of code is what we wished we had to deal with.

The Same Code, Made Beautiful

Let’s see the same example with that problem solved by a technique called Promises. Promises allow for chaining of asynchronously-executed functions.

Isn’t this easier to understand? Wouldn’t it be easier to look for errors or to add features to this version of the code? And it might surprise you that the two pieces of code are functionally equivalent. I even kept all of the variable names the same.

Considerations and takeaways

Somebody who is actually seasoned with code might argue the following: “They are not functionally equivalent: the original code had a lot of code dedicated to detecting errors and this version doesn’t.”

That is not correct – it is just that the error management has been moved out of your sight, but it is still there. Promises will handle errors as rejections and move up the chain. It means you don’t need to bother checking for errors everywhere, only when you need to.

The takeaway? Less clutter to the eyes, allowing you to focus on what’s important.

“But the previous code had a mistake in line 16 and this one doesn’t have any errors at all.” Good catch, my code-seasoned reader! The first approach did have the error your boss was complaining about in line 16. It was passing a wrong parameter as an error instead of a result, which meant that for every user without discounted profiles, the system would just show “error” instead of allowing them to check out.

If you weren’t able to spot that, don’t feel bad – it was intentionally hidden. This is actually another point that I want to make: simpler code makes it more difficult to make mistakes. In order to make the same mistake in the second piece of code, we would have to declare an error or reject a promise – that would have caught our attention immediately.

Beautiful Code is Readable Code

So, in the examples we’ve seen so far, having readable and “beautiful” code is actually a shortcut to code quality. It is also a shortcut to code maintainability, which translates to fewer errors (bugs), more developer productivity (faster features/fixes) and easier maintainability (faster features/fixes).

Beautiful code is readable code. It’s code that makes itself understandable right away. It’s code that allows you to make changes without adding much complexity. It’s code that makes our jobs easier and our customers happy – isn’t that a beautiful thing?