Reducing Headaches with Some JavaScript Best Practices

Check out my books on Amazon at https://www.amazon.com/John-Au-Yeung/e/B08FT5NT62

Subscribe to my email list now at http://jauyeung.net/subscribe/

Like any kind of apps, JavaScript apps also have to be written well.

Otherwise, we run into all kinds of issues later on.

In this article, we’ll look at some best practices we should follow when writing JavaScript code.

Declare All Variables First

To make finding variables easier, we can declare them at the top.

For example, instead of writing:

function foo(){
  let i = 100;
  console.log(i);
  let j;
}

We write:”

function foo(){
  let i = 100;
  let j;
  console.log(i);
}

This way, we won’t have a hard time looking for variable definitions.

We also don’t have to worry about hoisting when using var or function declarations.

Be Careful Using typeof

We’ve to know that typeof null returns 'object' .

So we can’t use it to check for null .

Also, typeof NaN returns 'number' , which is probably not what we expect.

So we shouldn’t use them to check for those.

Treat parseInt With Care

parseInt also have some quirks we’ve to think about.

It returns all of the number characters it finds converted to the number.

So if we have:

parseInt("11");

It’ll return 11.

And if we have:

parseInt("11james");

This will also return 11.

And if we have:

parseInt("11.22");

This also returns 11.

We should take note of these quirks so that we won’t get unexpected results when we try to convert non-numbers to numbers with parseInt .

Also, if the number starts at 0, it’ll assume that it’s an octal number.

So if we have:

parseInt("08");

then it’ll return 0 in older browsers.

However, in modern browsers, it should be converted as a decimal number.

Do Not Use Switch Fall Through

In each case clause of switch statements, we should have a break or return statement at the end of the clause.

For example, we write:

switch (val) {
  case 1:
    console.log('One');
    break;
  case 2:
    console.log('Two');
    break;
  case 3:
    console.log('Three');
    break;
  default:
    console.log('Unknown');
    break;
}

so that the JavaScript interpreter won’t run code below the case clause that’s matched.

Avoid For…In Loops

for-in loops should be avoided for arrays.

It doesn’t guarantee iteration order and it’s slower than the standard for loop.

It’s intended for iterating through an object’s noninherited and inherited properties.

This means the following loops aren’t equivalent:

for (let i = 0; i < arr.length; i++) {}

for (let i in arr) {}

If we want to iterate through an array in a shorter way, we can use the for-of loop:

for (let a in arr) {}

a is the array entry.

Avoid Reserved or Special Words

We shouldn’t use reserved words to define our own identifiers.

This may be allowed if strict mode is off.

For example, we may define functions like:

function foo(arguments){}

which is allowed if strict mode is off.

If it’s on, then we’ll get an error.

This is one good reason to turn on strict mode.

We can avoid defining our own identifiers that have the same name as a reserved word.

Be Consistent

We should be consistent with our code styling.

This can be done easily with ESLint.

It’s good at fixing these styling issues for us so we won’t have to worry about them.

Conclusion

We can reduce headaches by following some easy to follow rules.

The post Reducing Headaches with Some JavaScript Best Practices appeared first on The Web Dev.