There is a growing sentiment towards beautiful code. Everyone seems to be advocating for it. There is a multitude of tools, frameworks, and libraries that want to help you out. But for some of us, the idea of beautiful code is still a strange idea.
Isn’t code just code?
The reality of it is that it’s not. Code is actually a series of translated ideas that are used to compute the necessary experiences for a user. Ugly code can lead to an ugly experience — for both the user and the person maintaining it.
But what exactly is beautiful code? Why does it really matter? And how does it impact your code quality and sanity as a developer?
These are some of the questions we’ll be exploring. When it comes to code, true beauty is more than just the way it looks.
The traditional idea of beauty is based on the physical appearance of things. To be ugly is to be visually unappealing. However, when it comes to code, it’s more than just what we see.
Beautiful code is also an experience.
The way code works from a developer’s perspective is that it’s meant to be used and consumed by the person working on it. This means that it has to be comprehensible as much as it is to be syntactically correct.
The ability to easily comprehend code is based on length and complexity. The longer and more complex a particular class or function is, the more you have to mentally hold in order to digest and process what it’s trying to do.
Beautifully good code is when complexity has been successfully simplified.
It’s easy to write code. However, good and robust code requires planning and forethought with architectural planning and potential impact analysis. Without this, it is akin to building a house without some sort of blueprint.
As a developer of code, you play both the role of the architect and the builder. You can’t successfully construct something that is clear, clean and beautiful without playing both roles.
The purpose of the architect is to plan out how things are to fit together. The architect is able to step back and see where the inefficiencies are in the structures and resolve it before it gets built.
The builder’s role is to construct the code based on the resources available. How beautiful the final structure turns out is based on the developer’s repertoire of knowledge and techniques.
Beautiful code matters because it can indicate how stable your final application will turn out.
The stability of software tends to depend on how well things are able to fit together and its ability to withstand a change in circumstances and purpose for existing.
Beautiful code also indicates a high level of structure and order in the way ideas are translated from the brief and into code. When our translation is jumbled, so is the structure of our code and how they’re written. The ideas surround SOLID was created to give structure to the unstructured way of writing code many developers were operating in before its creation.
Code cleanliness is determined by how to streamline your thoughts are displayed and demonstrated for others to read. Many new developers often fall into the trap of creating mystery novels out of their code without understanding the side effects.
Beautiful code is not just simple but it also has a clear purpose for existing. When more than one reason for existing is coded into a function or class, it becomes brittle to change. This is because partial changes inside a class or function can result in a cascade effect on other parts of your app that may depend on it to work in a specific way.
What’s worst is when you’re working in a team and someone inherits code that is brittle to change. It limits the ability to reuse and reduce the amount of code needed, resulting in longer projects and a higher chance for code bloat.
Your ability to create beautiful code is based on your ability to abstract out the necessary parts, reduce down your code to just the essentials and write only what is required.
Writing beautiful code requires knowledge of standards and techniques. It also requires a deep understanding of certain features, ways of thinking about problems, and how to efficiently translate it over to your programming language.
Your quality as a developer is determined by how robust, effective, and efficient your ability to translate the requirements into something that is succinctly comprehendible across your team.
Code is written for humans as much as they are for compilers and engines. If the person inheriting your code cannot understand it, there’s a high chance of your application breaking in the future.
Beautiful code is also intrinsically lower in technical debt.
Technical debt is something that comes with all code. Higher levels of technical debt can significantly reduce the shelf life code. It can take longer to get things done. It does this by making it harder to implement, upgrade and pivot features. It also takes more time for developers to figure out the working parts and see how they can implement change.
There is a multitude of strategies and principles you can follow to increase your code’s beauty factor. However, there are a few foundational things that exist across different project types and languages.
Acronyms may feel cool and logical at the time but it’s not that fun to read unless you’re already initiated into the project somehow.
The problem with acronyms is that it turns your code into a secret novel that one needs to decipher in order to figure things out. Deciphering takes time. Deciphering takes even more time if there’s no documentation.
Single task is my most favorite principle out of SOLID. Why? Because it’s easy to understand as much as it is easy to explain to others. The rule is clear — your function should do one thing and one thing only.
If it does more than one thing, then it opens itself up to side effects.
Side effects are not fun because you have to deal with the ripple effect if things do change. Then it becomes a tracing game of where it is used and what for. Cleanliness is broken because now you’ve got a potential spider web of dependancy to deal with.
Sometimes we get a bit carried away and over abstract our code based on future predictions. While there’s nothing wrong with creating code to accommodate features that are coming soon, you mustn’t get too carried away.
Over abstraction can leave your code vague and hard to define. There’s a difference between planning for features that you know are definitely in the next few iterations vs. planning for something a year or two down the line.
By then, if you’re operating in MVP sprints, your code and its set of features may look significantly different from how you currently have it. It’s better to grow your code organically and cleanly over time than try to create the perfect app from the get-go.
The thing with beautiful code is that the more you create it, the more you’ll start to recognize the patterns. When this happens, you’ll also start to automatically curate and clean up your code as you go.
Optimization is a skill that is learned over time as you come to know the nuances of your particular language. That is why the deliberate code you write and refactor, the better you’ll get at writing clean and beautiful code.
Explore recent posts
//Explore recent posts
//
2 -min read
4 -min read
32 -min read
More Thought Leadership
//30 -min read
4 -min read
5 -min read