Categories
JavaScript Mistakes

Common JavaScript Mistakes to Avoid

Spread the love

There’re some very common programming mistakes that we want to avoid to keep our code clean and readable.

In this article, we’ll look at them and how to avoid each one.

Too Many Things in One Function

One function should do one thing only, which is whatever is indicated on their own.

If there’s something else, then it should be moved to its own function. Having too many things in one function makes it hard to read and follow.

For example, if there’s a function that gets both the subtotal and the taxes, then they should be split into 2 separate functions since they’re different.

Commented-Out Code

Commented-out code are code that won’t run. Therefore, they shouldn’t be there after we’re done with working on that part of our code.

Once we’re done, we should remove the commented-out or uncomment them.

Either way, the final product shouldn’t have commented out code in it.

Variable Names That Aren’t Descriptive

Naming variables in ways that don’t convey their meaning frustrate readers and ourselves once we forgot about that code we wrote and came back to it.

Therefore, we should name variables with names that describe what they hold.

Instead of writing let x; , write something like let numApples so that we know that our variable will hold the number of apples.

Magic Numbers and String

We shouldn’t have magic numbers and strings. Those are values that appear in multiple and mean the same thing, but it’s not explained explicitly in the code.

For instance, if we have the following code:

for (let i = 0; i < 10; i++) {  
  ///...  
}

Then we don’t know what the 10 means. Instead, we should set it to a named constant so that we know what it means.

For instance, we can write:

const numApples = 10;  
for (let i = 0; i < numApples; i++) {  
  ///...  
}

Now we know that 10 actually means the number of apples.

Messy Code Formatting

Messy code formatting makes code hard to read, so we should clean it up with a linter or a code formatter.

There’re plenty of choices out there, so we can use something like Prettier or ESLint to do the tidying automatically.

Hard Coding Values

We should never hard code values into our code, especially if they’re secrets. Instead, we should keep them as environment variables and read all the values from there.

There’re many ways to do that. For the front end, Angular, React, and Vue, for example, all have places to keep variables to keep variables for different environments in different files.

For the back end, we can use something like the dotenv package to read environment variables from a .env file so that we don’t have to hard code them.

The .env file shouldn’t be checked in, so we don’t have secrets in our code repositories.

Photo by Jens Johnsson on Unsplash

Repetitive Code

The repetitive code is bad. If we change something that repeats, we have to change them in all the places that they’re repeated.

Instead, we should move the common parts into their own file so that they can be used in multiple places.

The do not repeat yourself (DRY) principle applies everywhere. If we’re copying and pasting and using them exactly as is, then we should move them to a shared location.

Not Backing Up Code

We should manage our code with Git so that we can have a local and remote repo for our code.

This way we can keep one copy in a remote location automatically. Also, we can revert bad code easily and fetch code from earlier commits easily.

We can’t do that without version control.

If we don’t have our code backed up, then we may lose everything if something goes wrong.

Complicated Code

Complex code should be simplified so that we can understand them more easily.

We should also break them up into smaller parts so that we can reuse stuff and also have individual parts that are easy to read and test.

Conclusion

These common mistakes can easily be avoided if we’re careful about what we’re doing.

Breaking stuff to small pieces is always good, as with keeping things simple and not repeating things.

Commented out should be gone, and variables and values that aren’t descriptive should also be replaced with something with more meaning.

Leave a Reply

Your email address will not be published. Required fields are marked *