Poor naming. Huge functions. Bad architectural decisions. Duplicate code. These and so many others are common mistakes any developer will undoubtedly find when developing software. And while most software engineers will be happy to point them out when the code is written by someone else, they would find it harder to admit they commit those mistakes themselves.
However, if they truly want to produce better software they have to start admitting that, yeah, they often write subpar code. It can even happen to engineers with the best intentions, as tight deadlines or rushed projects might force them to just achieve the bare minimum and worry about the mistakes later.
Of course, this is a problem for everyone. For the users, that may end up with a buggy product. For the client, that doesn’t get the best software possible. And, believe it or not, for the developers too, as they’ll suffer when it comes to making changes, introducing new features, or even carrying out regular maintenance. In fact, those should be enough reasons for wanting to write better code.
The graph below is simple enough for everyone to understand how clean code impacts costs and time.
Image source: Geeks for Geeks
So, if you want the benefits from cleaner code, you should keep these 4 things in mind, that will help you on your way.
1. Keep it Readable
Pretty obvious stuff, huh? Any software engineer knows that code has to be easy to read. That’s especially true today, where it’s highly likely that you aren’t the only developer working on a specific piece of code. But even if you’re working on a solo project, keeping code readable is in your best interests.
Why? Because readability will bring you closer to a better understanding of your code and, from then, to easier support and maintainability. Sure, it isn’t the only thing you’ll need to truly understand your code, but if it isn’t readable, then all of the other things are practically worthless.
Fortunately, there are some fairly simple things you can do to improve your code’s readability. For instance, you can start by using meaningful names for everything from variables to classes. The idea is to use terms you can understand at a glance and that aren’t ambiguous.
Short functions are another thing that vastly improves readability. By following an easy rule for coding, you can make your functions shorter. You just need to remember that all functions should do only one thing.
There are more little hacks to get your code to be more readable. Maybe you have your own! Be that as it may, you should always keep in mind that you should never sacrifice readability since, as you may already know, you’ll spend more time reading code than actually writing it.
2. Prioritize Code Commenting
We said it above but it bears repeating – the fact that you are making your code readable doesn’t necessarily mean it’s understandable. Obviously, you’ll need a readable code for better understanding. Yet, sometimes, you might end up with a code that’s so fixated with readability that you start to misinterpret what you did.
For instance, certain names or the use of one-line wonders can be misleading or make assumptions about what the reader knows. To avoid all that, you can always add comments. And, yes, comments might not be a time-efficient resource for most developers but writing them can help your colleagues (or even your future self) when reviewing the code.
Code commenting is a desirable practice because it explains how your software works and what were your intentions behind it when you were coding. All of these becomes extremely useful in the maintenance phase, as it can help better understand each line of code and find other paths to new features or improvements.
3. Avoid Duplicate Code
You might be saying “wait a minute – everyone duplicates code. It saves time and effort!” And while you are right to point that out, the fact that a lot of developers are duplicating code doesn’t make it a good practice. In fact, reusing lines or blocks of code can create more problems than it can actually solve.
First and foremost, code duplication can make a software bulkier. This contributes to delays when running it in real-time by real users and drives space requirements up. Even if those delays are just a couple of milliseconds or the space it takes is small, smoothing those things out can lead you to a superior application.
Then, there’s the technical debt associated with code duplication. When introducing new features, making changes, or simply maintaining the software, this technical debt will make itself felt. You’ll then have to spend time simplifying or de-duplicating the code for the whole software to work better.
Finally, there’s the bug duplication that comes with reusing code and the increased security risks. The former refers to how you’re replicating any minor bug in the original code you’re duplicating. That means that, if you want to solve them afterward, you’ll have to fix every little instance of code duplication. As for security, duplicate code taken from somewhere else might have holes that you don’t know of, which exposes your software to unnecessary vulnerabilities.
The thing is – for all the negative sides of code duplication, there’s an easy solution. Just by moving the code into its own function or class to later call them from all the places where you used them, you’ll have a fix for this common problem while avoiding the associated issues.
4. Learn to Write Tests
A lot of software engineers roll their eyes when someone asks them to test their code. Why? Because most developers don’t like testing. In fact, a lot of them don’t even know how to write tests in the first place, which makes it even harder. And since testing is an essential phase of development, you can’t just put it aside.
Surely, you might argue that you can always hire a tester or outsource the testing tasks to a QA assurance team. That’s fine and all, but that doesn’t help you write better code. And you need to know how to write and execute tests to write better code! Want to know why? Because if you know that, you can write better code that will make it easier for testers to do their job. In the end, you’ll have a better product overall.
You want to know how to write tests for your code to be more testable. That means that someone will be able to verify your code programmatically and in a granular way. In other words, you make it easier for testers to verify very small units of code and how they behave. This translates to developing in a straightforward way – to write more testable code, you need to keep the number of code paths small, so they are easier to test.
A Direct Path to Better Code
When you read advice as simple as the one described above, you might start to wonder if things can be so easy. In a certain way, they can. Keeping your code readable, understandable, with the least duplicates, and thoroughly testable is a very achievable goal. What may be rough is the way to get there.
That’s because you’ll need to review how you actually code and start introducing conscious improvements to change. It’s hard not to fall into the same old vicious habits when you’ve been using them for so long. The complicated thing of writing better code, then, it’s to make that effort to change how you work on a daily basis.
Other than that, the path to better code is pretty direct. You only need the force of will to make it happen and you’ll be on your way there.
