Code Linting#
Key Points#
- Code should be validated with the following linters to ensure a uniform code-style and reduce errors.
- Linting rules typically have warning & error indicators for each rule and we treat them as follows:
- Warning: This should be avoided if possible, but can permit them into a code-base if there is sufficient justification in the code-review process. It can help to provide justification in a git-commit message or code-comment.
- Error: These should be avoided at all costs and should not be permitted into a code-base. Refactor the code that is causing the error.
- Some linting tools allow you to disable linting for various rules & lines-of-code at will (ex.
// eslint disable-next-line). Avoid these wherever possible and look to refactor the code to pass the rule instead. - Code that we did not write and do not plan on maintaining can be exempt from the linting rules. This is commonly present when working with code from:
- Software
- 3rd-party Libraries
- Previous developers/agencies
- Stores we built years ago
Linters#
Utilize the documentation from mvps-configs to setup your development environment for our linters.