JavaScript Best Practices — Source Files and Modules

JavaScript is an easy to learn programming language. It’s easy to write programs that run and does something. However, it’s hard to account for all the uses cases and write robust JavaScript code.

In this article, we’ll look at how to name our files and proper encoding for our files.

Also, we look at the right way to deal with modules.

File Names

File names should be all lower case and may include underscores or dashes.

We shouldn’t put any additional punctuation in our file names.

The file names should end in .js so that we know that it’s a JavaScript file.

For instance, foo.js is a good file name.

File Encoding

The encoding of the file should be UTF-8. This is standard across all platforms so that it won’t cause issues when we run them anywhere.

White Space Characters

The ASCII horizontal whitespace character should be the only one in source files.

Other whitespace characters should be escaped.

Tabs shouldn’t be used for indentation since they may be interpreted differently in different platforms.

However, tabs can be converted to spaces automatically.

Special Escape Sequences

Special escape sequences should have a corresponding numeric escape.

So \' is the same as \x27 , for example.

Non-ASCII Characters

We should use Unicode equivalent for non-ASCII characters in our code files.

Source File Structure

We may want to enforce some structure in our source files.

For instance, we may have JSDoc comments for documentation.

We may put them in folders so that there’s a clear hierarchy in our project structure.

ES Modules

Modules are used in most new JavaScript projects now.

Therefore, we should be mindful of some rules regarding modules.

Import Length

Length of import statements should be 100 characters or less so they won’t overflow the screen.

This way, no one has to scroll horizontally to read the whole line.

Import Paths

We should use the import sattement to import ES modules.

For instance, we can write:

import './foo';

or:

import * as foo from './foo.js';

or:

import { name } from './foo.js';

We don’t need the extension when importing files.

Importing the Same File Multiple Times

We shouldn’t import multiple members of the same file in different import statements.

For instance, instead of writing:

import { bar } from './foo';
import { baz } from './foo';

We write:

import { bar, baz } from './foo';

Naming Imports

We can name imports with the as keyword.

The name should be camelCase.

For instance, we write:

import * as fooBar from './fooBar';

Naming Default Imports

We can name default imports with camelCase also.

For instance, we can write:

import fooBar from './fooBar';

Naming Named Imports

Also, we can change the name of named imports so that we can use the name that we want to use.

For instance, we can write:

import { Cat as FatCat } from './animal';

for constructor imports or:

import { cat as fatCat } from './animal';

for other imports.

Named vs Default Exports

We can have named and default exports just like imports.

For instance, we can create a default export by writing:

export class Foo { ... }

and a named export by writing:

export { Foo }

Export Container Classes and Objects

We shouldn’t export container classes and objects

Therefore, instead of writing the following:

export class Container {
  static foo() {
    return 1;
  }
}

We write:

export function foo() {
  return 1;
}

export const FOO = 1;

Mutability of Exports

Don’t export variables that are mutable.

This means anything declared with let shouldn’t be exported.

For instance, instead of writing:

export let foo = 1;

We write:

export const foo = 1;

export from Statements

We should wrap export from statements so that it stays within 100 characters per line.

So we write:

export * from './foo';

or:

export { bar } from './another.js';

Circular Dependencies in ES modules

We shouldn’t create circular dependencies between ES6 modules, directly or indirectly.

For instance, we shouldn’t write:

b.js :

import './a';

and:

a.js

import './b';

Conclusion

We should be careful when working with file names and modules.

File names should be named in lowercase with underscore or dashes,

We should use modules and they shouldn’t have circular dependencies.

Code files should be UTF-8 encoded to avoid issues running them.