Functioning teams usually agree to code standards intended to make life easier for everyone. Unfortunately, we constantly flout those agreed rules - to our detriment. Not only does this lead to less manageable code, it can also lead to friction and discord within your team.
I think Alexander Pope put it best
Ah ne'er so dire a Thirst of Glory boast,
Nor in the Critick let the Man be lost!
Good-Nature and Good-Sense must ever join;
To err is Humane; to Forgive, Divine.
Ideally, we'd like to offload the contentious aspects of code review to an objective third-party that knows and understands our agreed rules. If we can rely on trusted code to critique code we write then we can all hate that code instead of each other.
Fundamentally, using code to check our code is faster and (usually) free from errors or bias. This is why we use linting tools, driven by the rules we agree on pre-defined metrics such as line-length, cyclomatic complexity, nested callbacks and others I've mentioned in an article on finding the most complex files using eslint.
Underline it with a rule
There are already lots and lots of existing rules https://eslint.org/docs/rules/#best-practices that you should be using right now. If you use eslint you probably already use a number of these rules either commonly by using eslint:recommended or airbnb. Most teams should add their own rules or use overrides to change or remove airbnb/recommended rules they don't agree with.
A good approach to use when first introducing eslint rules is to regularly discuss their current use and how well they support your code standards; are the parameters properly tuned (what level of cyclomatic complexity should you find acceptable? only your team will know...), should they be warnings or errors, and which new rules should be introduced, and which are getting in the way and should be removed. Eventually, it will be a rare event for you to revisit your eslint config.
Don't break the rules - make your own
It is likely that you'll have situations where the standard eslint rules are insufficient. What I'm suggesting here is a small step beyond using pre-defined rules - you can write your own eslint plugins to enforce your own code standards. There are two main approaches to writing your own eslint rules - both of which I will cover in future articles in the series on abstract syntax trees:
- AST selectors
- writing a
propereslint rule
Rules are agreed to as a team and built as a team
Everyone needs to be involved in deciding which rules to use as well as implementing and maintaining the configuration of existing rules. Happy, functioning teams are built on solid communication and a large dose of cross-functional capability - the latter would be important in successfully employing this approach. Practically, it would quickly become a bottleneck if only a small number of developers know how to write the eslint rules, they won't get updated as frequently and they can quickly become a hinderance resulting in them being removed from the codebase.
Also, more to the point, if a small number of people are responsible for writing the linting rules they will be blamed rather than the code - however irrational that might be!
Can code snippets be used to enforce standards?
Yes, but no.
Code snippets are great, but there are a number of drawbacks. The main stumbling block, in my opinion, is affordance; developers need to know the snippets are there, and they need to know how to use the snippet.
Also, this is compounded by the fact that many teams do not enforce use of a single IDE. For instance, my team uses a mix of Webstorm, VS Code, and Sublime. The overhead in adding, maintaining and documenting code snippets for each of those editors is just more friction to the adoption of code snippets.
As much as possible, code standards checking should be automated, the point being to strengthen the weakest link in the chain: the developer. Relying on a developer to pick a code snippet when writing code, or notice that a snippet should have been used when reviewing code does not address the issue that snippets are meant to fix.
Not that snippets are not useful - use them if you like them, I do, but don't expect other developers to do the same.
Know your place
In short, to make your life easier, shorten your code reviews (a bit), and promote harmony and good-will within your team (well, probably), let the rules bind you and bend the knee to the eslint overlords!
Top comments (1)
You can pry my ending semicolons from my cold, dead, hands. 😤