Clean JavaScript checklist

• Proper logger with a default log level.
• Unit testing of code. Unit tests have a chance to fail. Unit tests which can only pass are not useful.
• Environment variables.
• Strict linting rules.
• JSDoc for code.
• Proper README.
• Extensive .gitignore to ignore everything unneeded.
• Dockerfile file and docker-compose file included.
• Swagger API documentation with correct HTTP codes.
• Exception handling when dealing with API.
• Clear and readable error messages from API.
• Continuous integration.

Explained

Proper logger with a default log level.

A proper logger should not be confused with console.log, which offer literally no configuration possibility at all. A good logger should have at least the 5 following log level:

- TRACE
- DEBUG
- INFO
- WARN
- ERROR

For programming debugging in development the DEBUG level should be used. For debugging in production the WARN and ERROR should be used for exceptions handling.

Unit testing of code. Unit tests have a chance to fail. Unit tests which can only pass are not useful.

Frontend as well backend can be tested. Tests should be written when the functionality is not trivial. The tests should also be able to fail. Tests like following are not useful

assert(1 === 1);

Environment variables

Environment variables like API key, email's password and database's password should never be hard coded. Instead, employ usage of environment variables. The environment variables should also have multiple profiles, for example

.env.example 
.env.development
.env.production

Every profile except for .env.example should be excluded by .gitignore.

Strict linting

A good JavaScript should always employ a strict linting. The linting process can be simplified by employing a prettier tool.

JSDoc for code

JSDoc is a framework used to document code and publish the documentation for working with other teams. An example of JSDoc could looks like following

/**
 * Represents a book.
 * @constructor
 * @param {string} title - The title of the book.
 * @param {string} author - The author of the book.
 */
function Book(title, author) {
}

The documentation should non-trivial and give your teammates more information about what the code does.

Proper README

A proper README should give every non-trivial information about the project likes:

• What does the project do?
• Which API does this project use?
• Website for the documentation of the project?
• How to setup the development environment for this project?
• Which steps are needed to deploy the project?

Extensive .gitignore to ignore everything unneeded

A proper .gitignore should only includes everything of the project that is needed for further development and deployment. Typical content can look like this

.env
.env.production
.env.development
.env.staging
.idea/
node_modules/
dist/
build/
*.log

Dockerfile file and docker-compose file included

Dockerfile and docker-compose are the minimum documentation of how the deployment looks like. The docker-compose file should contains everything needed to start the project. The only thing a visitor needs to do is entering docker-compose up -d --build into the terminal.

Swagger API documentation with correct HTTP codes

The swagger tool chain https://swagger.io is the argueablely one of the best tool to document a REST API

Exception handling when dealing with API

An API in this case is everything that works with

• network
• database
• asynchronous

Dealing with API always exposes a certain risk of error.

try {
  // API
} except(e){
  log.error(e.stack)
} finally {
  // Close resource
}

Clear and readable error messages from API

When writing backend API, always return a proper message if an error happens. This will help frontend developers a lots. Tools like https://express-validator.github.io is extremely helpful for this purpose.

Continuous integration

Every web application project should contains a continuous integration like Travis-CI or GitLab-CI. The pipe should run linting, testing everytime a new commit is made to make sure errors can be detected as early as possible.