JavaScript Best Practices — Modules and Identifiers
Tags: javascript, webdev, programming, codequality
Published: 2021-01-26 21:42:42

**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/**

To make code easy to read and maintain, we should follow some best practices.

In this article, we’ll look at some best practices we should follow to make everyone’s lives easier.

### Minimum and Maximum Identifier Lengths

We should make identifier descriptive so they definitely shouldn’t be too short.

It also shouldn't be too long.

If it’s too short, it’s probably not descriptive enough.

If it’s too long, then it has redundant information and takes up too much space.

So we shouldn’t write:

```
const x = 5;
```

since we don’t know what `x` is.

But we can write something like `const numApples = 1;` .

### Location of Arrow Function Bodies with Implicit Returns

We should put arrows in a logical location.

For instance, we can write:

```
(foo) => bar;
```

or

```
(foo) => (bar);
```

or

```
(foo) => bar => baz;
```

They are conventional and logical.

It’s better than these examples:

```
(foo) =>  
  bar;
```

or:

```
(foo) =>  
  (bar);
```

The first examples are more compact than these ones.

### Default Imports

We’ve have a default export for a default import to work.

For instance, we should write:

`foo.js`

```
export default function () { return 100 }
```

Then we should import it by writing:

```
import foo from './foo';
```

For CommonJS modules, we can write:

`foo.js`

```
module.exports = function () { return 100 }
```

Then we can import it by writing:

```
const foo = require('./foo');
```

### Repeated Imports and Exports

We can only have one default export in each module.

For instance, we can’t write:

```
export default class Foo { /*...*/ } 
export default class Bar { /*...*/ }
```

We have to remove one of them.

If we remove one:

```
export default class Foo { /*...*/ }
```

Then we can write:

```
import Foo from './foo';
```

### Export Statements that Come Before Other Statements

We shouldn't have export statements that come before other statements.

For instance, we don’t want to fix statements like:

```
const bool = true
export default bool
const str = 'foo'
```

Moving all exports to the bottom would make it easier to read.

### Use of File Extension within the Import Path

When we write imports, we don’t need an extension for JavaScript files.

For instance, instead of writing:

```
import bar from './foo/bar.js';
```

We write:

```
import bar from './foo/bar';
```

However, we should put the extension for JSON import.

For instance, we can write:

```
import bar from './bar.json';
```

We may also do the same thing for JavaScript files that don’t have the `.js` extension.

For instance, we can write:

```
import Component from './Component.jsx';
```

for JSX files.

### Putting Imports First

We should put import statements first.

For instance, we should put them at the top.

Instead of writing:

```
import foo from './foo'
doSomething(foo)
import bar from './bar'
```

We write:

```
import foo from './foo';  
import bar from './bar';
doSomething(foo);
```

### Grouping Exports

We can group exports together to make finding them easier.

For instance, we can write:

```
const first = 'foo';  
const second = 'bar';
export {  
  first,  
  second,  
}
```

With CommonJS modules, we can write:

```
const test = {};  
test.foo = true  
test.bar  = true
module.exports = test;
```

We also grouped the exports together.

### Named Exports

We can import named module members in various ways.

Given that we have:

```
export const foo = "foo"
```

We can write:

```
import { foo } from './foo'
```

Also, we can write:

```
export { foo as bar } from './foo'
```

to export it as `bar` .

We can also import it as `bar`:

```
import { foo as bar } from './foo'
```

### Newline After Import

After a group of imports, we can put a new line to separate the imports from the rest of the code.

For instance, we can write:

```
import defaultExport from './foo'  
import { bar } from 'bar'  
  
const foo = 'bar';
```

or:

```
const foo = require('./foo')  
const bar = require('./bar')  
  
const baz = 1;
```

for CommonJS modules.

### No Absolute Paths

We shouldn’t use absolute paths for imports because it’ll only work on the current computer’s current folder strucutre.

If we move it anywhere, it won’t work.

So we shouldn’t write:

```
import f from '/foo';  
import bar from '/some/path';
```

or:

```
const f = require('/foo');  
const bar = require('/some/path');
```

Instead, we write:

```
import f from './foo';  
import bar from './some/path';
```

or:

```
const f = require('./foo');  
const bar = require('./some/path');
```

### Conclusion

We should write our imports and exports properly.

Never import with absolute paths.

And we should group them together.

Identifier lengths shouldn’t be too long or short.