Linting is controversial. Linting is the cause of many debates. Linting can be one of your most powerful tools, if done right. If you’ve spent any time in the front-end development ecosystem, you’ve most likely heard the word “linter” or “linting”. My definition of linting is, “The systematic application of preferential best practices in coding,” with a heavy emphasis on “preferential”. The easiest block of linting rules to justify are those which relate to the prevention of unexpected bugs through ambiguity, such as nested scope declaration of variables. This block of rules addresses coding techniques which teams will unanimously call wrong.
For me, the next block of rules surrounds version control diff management. These rules are opinionated, but in my view, carry a bit more logic. For example, we might consider the notorious example of tabs versus spaces, carriage returns, or even trailing commas. Getting buy-in on this block isn’t too hard as they don’t affect the day-to-day life of developers.
The block of rules I’m talking about today though are those rules which lean heavily into the preferential category. This can be something like destructuring versus dot notation. Whatever justification used for the rule can be used against the rule. The simple enforcement of these rules alone adds zero value to your code base. The case I’m making though is the value added by making the cognizant choice to define preferences and capture in enforced linting rules.