When we take our first steps into the wonderful world of programming, we get to see for ourselves what it does for millions of people. It’s thanks to programming that the lives of so many are made easier, just by pressing a few keys on their devices (This is magic).

Programming is another kind of superpower, but as Uncle Ben said to his nephew, Peter Parker, “With great power comes great responsibility.” In the world of programming, our greatest responsibility is to ensure that the code we write is both easily testable and will remain maintainable over time.

There are some small practices in programming that can have a continuously negative impact on the code we write and the product we create as the end result. I’ve experienced these issues firsthand. It’s important to share what they are and why you should avoid them at all costs.

1. Using var instead of let and const

It’s time to say goodbye to using var.

You should use only let and const for these reasons:

● The scope is clearer (between braces).

● It does not create global objects.

● It flags errors if you redeclare them.

Unless you’re using an older browser such as the beloved IE11, it’s in your best interests to let go of var. Let and const will be your best friends going forward.

2. Using comments to explain the code

Comments are a fundamental part when we build software, they help us to understand a little better the code we are reading, but we must not fall into the error of explaining step by step what our code does, we must create code that is easy to read and comments should only provide context.

Here are a few tips and reminders to help you write code comments like a pro:

● Avoid redundancy in your comments; don’t write what you do, write why you do it.

● Descriptive variable/function/class names are better than descriptive comments.

● Summarize as much as possible; do not write paragraphs if it is not absolutely necessary.

● Try to always use the same language and style of comments.

● Over time, comments are not usually maintained (modified) code is.

3. Using == instead of ===

The first thing to understand is that although visually they are very similar, they do different things: the first is called regular equality operator (==) and the second is called strict equality operator (===).

The regular equality operator (==) only checks if the operands are similar, which can cause some unpleasant surprises.

The strict equality operator (===) always checks that the operands are of different types and values and that they are exactly the same.

4. Forgetting to use optional chaining

The optional chaining operator (?), allows you to read the value of a property located deep in a chain of connected objects without having to check every single reference in the chain.

This helps us avoid errors when trying to access a non-existing property. As an example, let’s say we have a Pokémon object that contains the information of that Pokémon.

When we want to access a property that is not defined, such as in this example, accessing the property ‘attack’ Javascript will generate an error, and our application will break. When using optional chaining (?), Javascript will tell us that the property is undefined but will not generate any error. Thinking about these types of errors that are sometimes out of our control makes a big difference in the long run.

5. Not using magic strings and magic numbers

A magic number or magic strings are numbers or strings used directly in the code which often do not have a clear context but do have a purpose. It is best to assign these values to constants, as they can become difficult to understand and debug otherwise.

6. Improperly handling API call errors

We should always handle errors with a try/catch in our async/await.

If we do not handle the errors in our promises, it is very likely that our application will explode, and believe me, we do not want that to happen.

7. Using an object as a single parameter

When declaring a function where multiple values are expected from an object, it is best to use multiple input parameters instead of single object inputs. This helps us with several things:

First, it makes our code easier to read by knowing from the beginning what parameters our function needs.

Second, it makes the function easier to test, and these two things together helps our product to be maintainable over time. Also, as a plus, it improves the performance of our application as it avoids collecting garbage or creating unnecessary object parameters.

Another plus is that if you use TypeScript and you have several parameters, it is easier to define the interface of the parameters to benefit from type checking and auto-suggestions which makes us avoid errors.

8. Forgetting the power of abbreviations

We have all been in the position of wondering if a variable exists or if it contains some kind of value other than null or undefined. Because of this, we often end up doing super long validations of this type:

Abbreviations help us avoid this problem. In a simpler and more elegant way, the above code can be reduced to just the following:

Conclusion

Writing clean code will always be our responsibility. In my experience as a developer, I have learned that having maintainable and easy-to-read code will save you and your team many hours.

Remember that we spend more time reading code than writing it. I hope these little tips will facilitate your task of creating magical and amazing products.

If you have any suggestions, please share them in the comments section. Together, we can continue to grow.

‍