How To Write Quality Code: A Simple Guide
Writing good code is a goal that should be on every developer’s to-do list. In the beginning we are learning the ropes and getting used to seeing code everywhere, so we don’t worry too much about the right or better approaches—we just want code that works.
However, as we start to get used to coding, “make it work” doesn’t cut it anymore. We then wonder if what we are doing is actually our best, and if not, how we can improve.
If you want to ramp up and improve yourself, you will have to take your coding to the next level. This guide will help you understand what it takes to write good code and the mentality that you need to never look back.
Don’t Stop With the Big O
If you’re not a computer science graduate, you probably haven’t worked a lot with Big O. Big O is a mathematical notation that allows the measuring of a computer algorithm’s speed and memory size when hypothetically there are infinite inputs.
It’s a great measure for code efficiency and cost, but beyond that, Big O can’t measure anything else. It is a mathematical tool used to measure complexity in our code; however, it doesn’t weigh the human variable, the specific system requirements, or our software architecture.
I’m not suggesting you should neglect Big O, but you should take it for what it is—a mathematical approach that forms part of the criteria of what is quality code—and by no means take it as the absolute measure. Big O is a good starting point to measure your code quality, but don’t stop there. You still have work to do.
Aim for Code Persistence
Code persistence is one of the most undervalued factors in what makes quality code. In a nutshell, it’s the measure of how much of your code will live through all stages of generating and maintaining production code—from feature idea to final test and deployment, and through refactoring, debugging, and the implementation of new features on top.
Think about how much of your code passes through all those filters and makes it to the finish line and, more importantly, how much of it stays there through all new revisions and future implementations.
It’s a waste of time and a huge roadblock when some code has to be partially or entirely rewritten because nobody knows what it does or how it works or because it’s more cost-effective to write it from scratch instead of trying to make it work. That piece of code is not quality code, and it’s not persistent through the changes that happen over time.
Systems can change, and so can requirements and technologies, but good code will survive with little or no modification.
Next time you’re writing code, sit and think “How can I solve this problem in a way that only needs to be coded one time?” The solution will not be as obvious as you might think. Get imaginative and create some great code.
Technical Solutions To Boost Your Coding
There are a plethora of plugins, add-ons, and formatting standards, but most likely you will be forced to use specific tools or standards on a specific job. But don’t see that as a bad thing. On the contrary, limitations will force you to learn new coding patterns and be flexible with your skills.
These tools will help you be organized and uniform about your code, but they won’t do the work for you. The best tools you have are being conscious about what you are doing and consistent about it.
Here are some technical ideas to improve your code quality:
- Use a linter.
- Adhere to a coding standard.
- Comment your code appropriately.
- Use good names (variables, functions, etc.).
- Don’t neglect proper testing.
- Take advantage of automated code review tools and continuous integration tools.
- Share your code and ask for feedback (code review).
- Be aware of the project’s big picture.
- Pair programming with an experienced developer.
- Stay up to date on updates and new libraries.
- Read Code Complete and Clean Code.
Getting technical with your code can be a huge help, but that also can set you back if you don’t know how to use your tools properly. Find that sweet spot where you leverage technical knowledge without wasting time over-engineering your code.
Write “Human Code”
Kyle Simpson has explained the idea of writing “human code,” meaning writing code with the explicit idea that it is for us, not for the computer. Yes, the computer will compile, link, execute, and interact with the code, but nowadays there are so many layers of abstraction, that our code barely translates its exact intention. So it’s pointless to “save” some characters here or to use font ligatures because they will parse faster.
This “human code” idea is brilliant. It allows you to write programs as legibly and easy to understand as possible, always thinking about our future self or co-workers that will deal with it.
Of course you should make sure you don’t diminish performance (Big O) and other factors like coding standards, but always have in your head that this is a message for a human being and not just pieces of code to make something work. This is a huge mentality switch that will help you write better code.
Use Common Sense
One of the big hassles of changing jobs is getting to know the new codebase. Anyone disagree? I thought not. Swimming in that huge pile of old and new spaghetti of uncommented code can be nerve-wracking. But after a few weeks, it all starts to make sense.
Do yourself a favor and use common sense about how you’re fitting your new code into the old codebase. Your new code can be slick and fast, elegant and communicative, but if it is on the wrong file, or the wrong scope, or the wrong block, it will still look out of place. Context is important; where you fit your new code is important. Remember you’re writing code for you and your co-workers—where you park it could generate great confusion or insightful clarification.
Design patterns in the codebase mean a lot, so don’t disrupt them. Go with the flow. If your project bets heavily on functional programming, don’t go around creating classes and methods like a maniac; it will look bad on you, and it will confuse everyone. Writing good code is where instinct meets knowledge. It takes time to get both, but the reward is a true form of art.
Five Questions To Ask
Before you ship any code, there are five questions you should ask that will exponentially increase your awareness of whether what you’re uploading is good or just another temporary solution.
Before every commit, try to answer these questions:
- Does your system break if you make a bad change to one part of your code?
- Can your code be reused on another part of the system?
- Can your code be updated or upgraded easily over time without adding bugs?
- Is your code easy to understand, and does it follow logically?
- Is your code efficient and small in size?
If you cannot give a clear and satisfactory reply to any of these questions, it means you should go back and reconsider your code. Pretending a problem doesn’t exist won’t make it go away.
Hasta la Vista … Baby
Sometimes it is just better to rewrite the whole thing. Old technology, a bad codebase with a lot of bugs, new requirements that need completely new architecture, and escalation issues are several reasons why this can be a viable option. For whatever reason you are considering it, make sure it’s the right decision and that next time you get it right and make code that will last.
Writing quality, long-lasting code is not only possible but necessary. In June 2019, Tidelift and The New Stack jointly fielded a survey of professional software developers, showing that 70% of a developer’s time is spent reading code, and the average output is about 10 lines of code per day. This means that we spend a lot of time figuring out how the heck our system works instead of actually writing some code.
Like everything in life, great code is about balance; there is no one-size-fits-all answer. It depends on your system, your inputs, and the results you want to achieve. But you need to know how to tip the scale and compare, how to go back and adjust, and how to write code that never dies.
This guide will help you write better code. Don’t just read it. Study it, share it, give some feedback, and above all apply it.
Great coders aren’t born like that; they strive to be better over time.
Remember, keep calm and code away!