How To Write Quality Code: A Simple Guide
Published: 2023-04-16 20:49:47

---
title: How To Write Quality Code: A Simple Guide
published: true
date: 2023-04-16 20:33:43 UTC
tags: 
canonical_url: https://carlostrujillojs.com/how-to-write-quality-code-a-simple-guide
---

<iframe style="border-radius:12px" src="https://open.spotify.com/embed/episode/3y8pUfMbC5CtzJR0zqTjXb?utm_source=generator&amp;theme=0" width="100%" height="352"></iframe>

**Writing good code** is a goal that should be on every **developers to-do list**. In the beginning we are learning the ropes and getting used to seeing code everywhere, so we dont worry too much about the right or better approacheswe just want code that works.

However, as we start to get used to coding, make it work doesnt 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.

## Dont Stop With the Big O
<iframe src="https://gifer.com/embed/9pku" width="480" height="350.400" style="margin:0 auto"></iframe>

If youre not a computer science graduate, you probably havent worked a lot with [Big O](https://www.freecodecamp.org/news/big-o-notation-why-it-matters-and-why-it-doesnt-1674cfa8a23c/). **Big O** is a mathematical notation that allows the measuring of a computer algorithms speed and memory size when hypothetically there are infinite inputs.

Its a great measure for code efficiency and cost, but beyond that, Big O cant measure anything else. It is a mathematical tool used to **measure complexity** in our code; however, it doesnt weigh the human variable, the specific system requirements, or our software architecture.

Im not suggesting you should neglect Big O, but you should take it for what it isa mathematical approach that forms part of the criteria of what is quality codeand by no means take it as the absolute measure. Big O is a good starting point to measure your code quality, but dont 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, its 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.

Its 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 its more cost-effective to write it from scratch instead of trying to make it work. That piece of code is not quality code, and its 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 youre 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
<iframe src="https://gifer.com/embed/6tp" width="480" height="271.543" style="margin:0 auto"></iframe>

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 dont 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 wont 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](https://simpleprogrammer.com/commenting-coders/).

- Use good names (variables, functions, etc.).

- Don't forget about cache invalidation (jk 🤣🤣🤣)

- Dont neglect proper testing.

- Take advantage of [automated code review tools](https://kinsta.com/blog/code-review-tools/) and [continuous integration tools](https://www.atlassian.com/continuous-delivery/continuous-integration/tools).

- Share your code and ask for feedback (code review).

- Be aware of the projects big picture.

- Pair programming with an experienced developer.

- Stay up to date on updates and new libraries.

- Read [_Code Complete_](https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?crid=31ECMZ0H6WXOV&dchild=1&keywords=code+complete&qid=1618924433&sprefix=code+compleet%2Caps%2C163&sr=8-1) and [_Clean Code_.](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?dchild=1&keywords=clean+code&qid=1618924414&sr=8-1)

Getting technical with your code can be a huge help, but that also can set you back if you dont 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](https://github.com/getify) 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 its 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 dont 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
<iframe src="https://gifer.com/embed/2ob" width="480" height="486.417" style="margin:0 auto"></iframe>

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 youre 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 **youre writing code for you and your co-workerswhere you park it could generate great confusion or insightful clarification**.

[Design patterns](https://simpleprogrammer.com/software-design-patterns-hiding/) in the codebase mean a lot, so dont disrupt them. Go with the flow. If your project bets heavily on functional programming, dont 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 youre uploading is good or just another temporary solution.

Before every commit, try to answer these questions:

1. Does your system break if you make a bad change to one part of your code?

2. Can your code be reused on another part of the system?

3. Can your code be updated or upgraded easily over time without adding bugs?

4. Is your code easy to understand, and does it follow logically?

5. 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 doesnt exist wont make it go away.

## Hasta la Vista Baby
<iframe src="https://gifer.com/embed/Xnvx" width="480" height="301.714" style="margin:0 auto"></iframe>

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 its 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. A survey from Tidelift and The New Stack of professional software developers, showed that 70% of a developers 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. Dont just read it. Study it, share it, give some feedback, and above all apply it.

**Great coders arent born like that; they strive to be better over time.**

Remember, keep calm and code away!

Carlos