JavaScript Variable Best Practices
By: Arthur Frank
Tags: Learning, Best Practices, Clean Code, JavaScript, Variables

Naming convention

Giving a good name to your variable is crucial. How you name your variables will decide the future of your application codebase.

It will dictate how easy it is:

To understand your code

To navigate it

To maintain it

So what we can do to genuinely improve naming?

Use Case-separation

There are a few known case-separators

These are major case-separators. As you can see the main purpose of using them is to separate words in your variable names. This way your code will already be much easier to read.

Let’s do a quick comparison:

So the benefit is quite obvious but which one to pick? I will give you few tips:

If your codebase already uses one of the conventions, just follow it — keep consistency, even if it is not your favorite. If codebase is messy or doesn’t have any conventions, pick one and follow it. In that case you will have to protect your choice and make sure others are following it too. If you are working with JavaScript the agreed standard is to use camelCase for variables, object properties, functions and object methods. PascalCase is often used for class names.

For example:

5. SNAKE_UPPER_CASE is often used to symbolise application level constants. Usually to contain configurations needed for your app to function. For example it may contain some API connection strings, tokens, constant value for app settings, like number of connections etc.

Meaningful names

There is a concept of self documented code which you may have heard of. It basically means that you document your code, by giving good, descriptive names to your variables and functions, that people can read like a book, and understand what is going on. It’s quite a difficult craft, that even senior engineers struggle with it from time to time. But it’s definitely possible and worth getting better at.

So first things first, try to forget about things like a, b, c names. Loads of tutorials will be using these to simplify examples, but in real codebase these names are really bad because they do not mean anything.

You may think that a short variable is better, because you save bites in your code etc. But this is mainly false, especially if we talk about JavaScript. Your code will be minimised and transpile for production anyway. So all your well written names will end-up being exactly a, b, c in your browser. But for Engineers, while you work with the code, keep it as descriptive as possible. Few examples of bad VS good:

So don’t be afraid to make a little bit bigger but more descriptive name. And don’t be lazy too. People love to shorten names to save milliseconds of time, but they do not realise they and others will spend minutes or maybe even hours to figure out in three month what was meant by uau .

Try to not over-explain your variables too, so for example something like userObject or basketListArray will be a bit overkill. People should have IntelliSense in their IDE's and if you name variables wisely it will be obvious what type of content there will be.

Rule exceptions

Sometimes you may have to loop through an array and you need an iterator, which usually is named as i , or you may need some math operations. In these cases people often use x, y names etc. These will be exceptions from general rules.

For majority of your code, I hope you got the idea 💡.

Declaration

Try to declare you variables as higher to the top as possible. Ideally stack all declarations together if possible or at least group them. This will give you and other devs better idea what variables you have used in further code as well as you will always know where to look for initial declarations if you need them. So try to avoid creation of variables on fly in the middle of your scripts.

Mutability & Scope

Good programming practice is to build your application with everything closed, scoped, and protected as much as possible. This is needed to prevent potential bugs. And to ensure your code will be used right.

So in JavaScript there is not many ways you can protect your code privacy. But what you can do, is use const and let to prevent mutations and control scoping of your data.

So a good practice would be to use keyword const for every variable declaration and change it only when it's really needed. And use let over var if you need mutable data, but you will still be in control of scope. This way you will reduce potential to bugs in you code.

Wrap-up

That’s it folks, thanks for reading this post until this point. It end-up being quite long article. I hope you enjoyed it. If you have any question or you want to know more, put comments down bellow.