Raising the bar for code quality at scale

[phillip-le]

Suppose there are three broad categories for code quality:

• Lowest level you have things that you can lint: stylistic conventions, eslint best practices, no unused variables
• Highest level are your broad principles that you are trying to adhere to: do you have leaky abstractions, SOLID principles, domain driven design principles. These are the things that may be impossible to lint effectively / require the nuance of context to apply
• Then, you have everything else in between. These might be language specific code quality things like how to improve type safety, having good documentation

What I want to talk about is how we can slowly raise the bar for the lowest level. In other words, how to introduce new linting rules.

First, pick a linting rule that you want to adopt.

Add it to your eslint config and set it at error. It is important to NOT set it as warn because it is very commonly ignored and very hard to prevent new linting violations from being introduced. What we want to see is that the number of violations decreases over time.

Use eslint --fix to take care of the easiest cases.

Then, use https://github.com/mizdra/eslint-interactive to add individual disable-eslint lines with a TODO comment on every instance of the rule violation. Usually, for large codebases, the effort to retroactively make a codebase compliant is huge and not worth it but the benefits of preventing future instances can be huge for quality.

Optionally, create a codemod that will attempt to autofix the problem like https://docs.grit.io/patterns

https://eslint.org/docs/latest/use/command-line-interface#--report-unused-disable-directives Ensures that every disable eslint comment is having an affect. Helps with simplicity over time.

Why is linting important? We shouldn't be focussing on things that can be lintable in pull reviews. Investing in automation has massive ROIs. From a developer perspective, it is a lot easier to digest a machine telling you what you're doing wrong than receiving a dozen comments on a PR.

Also, shill for ls-lint and knip

[udaniesalgado]

Why is linting important? We shouldn't be focussing on things that can be lintable in pull reviews requests. Investing in automation has massive ROIs. From a developer perspective, it is a lot easier to digest a machine telling you what you're doing wrong than receiving a dozen comments on a PR.

Also shortens the feedback cycles as you're writing code, and reduces the time for PR reviews as reading the code is much easier and adheres to the team's coding patterns.