When doing code reviews, you might find yourself having to point out inconsistencies in your team's coding style that a linter can't catch. Things like naming variables, file structure, etc. And sometimes having to do this and having to explain why a coding style is preferred over another can affect the time a PR gets merged.
One of the ways you can address is to create a GitHub wiki. If you have a standard for naming arrays as nameList instead of names, document it there. If your team prefers to import lodash functions like import _get from 'lodash/get;' instead of import get from 'lodash/get';, add it there. But make sure that you have discussed the pros and cons with your team before you put it there.
The result is a faster code review process because of two reasons. First, you can use that wiki as a guide when doing code reviews. Second, when a new developer comes in and a coding style was not followed, you can just refer to the wiki without having to explain why a coding style is preferred over the other.
Top comments (2)
What tools do you use to enforce coding styles that a normal linter can't do?
Rubocop is wildly configurable and has cops for many, many conventions. I also publish a style guide for things I cannot express in cops. But, if I can automate and enforce it with Rubocop, that's my preference.