JS code quality starter pack: linters, conventions, best practices

dev.to article

This article is about my view to convention building.

It includes some basic examples including linting tools setup.

That can be interesting for developers who like to follow coding best practices and who want to improve their own or team code quality.

As for me, I've explained and use those concepts many times. So, putting them into article will be handy.

First of all you can look at my linting guide with the linter pack setup here.

Also you can grab my article from git repo here.

What is it for

  1. Put and keep things in order together.
  2. To make productivity a little bit higher, and also reduce the volume of work.
  3. Conventions supports convenience of:

How to make it

  1. Conventions should respect team's/framework's abilities and limitations.
  2. Conventions is always a compromise. You should learn how to do that before doing conventions.
  3. Compromise is based on the trust, and that's based on the respect and responsibility.
  4. Respect yourself and others results of the work and time which has been spent.
  5. Prepare and make discussions well:

Rules for the PR reviewer

  1. reduce the number of reviewers
  2. check all code at once, reduce review-fix(ping-pong) time spending
  3. actions:
  4. check the:

Rules for the PR author

  1. Less code means less:
  2. Do not shorten unit's names or line breaks:
  3. describe PR's scope in a task to help make the review and a test better:
  4. reduce the PR's scope, make a new subtask/story for:
  5. execute before the pushing into repo:

Rules for code quality

  1. make functions private as much as possible
  2. use camelCase
  3. remove an unused code
  4. reduce the code complexity:
  5. make names readable like:
  6. put notes to share your knowledge
  7. make separate unit test assertion for:
  8. add in every unit test not only the final state, but state transition: before/after loading, before/after issue fixing