Writing Your Own Code Rules

When the project development reaches a certain stage, resources need to be invested in building a code protection mechanism. This opportunity is difficult to define accurately. It is roughly before the project is running stably for a long time and some problems begin to emerge, but it is not yet completely in chaos. Avoid premature optimization, and also avoid, well, too late optimization.

Some tools are very easy to implement and are usually available early in the project. For example, the Prettier code formatting tool can maintain code specifications in real time. There are also many similar tools that can be used directly during the encoding process, such as accessibility, compatibility, security code checking, etc. Webhint integrates a large number of such tools, which is worth a try.

There are also tools that need to write more code to protect your code. Testing is an important part of it and can even be set to run during encoding. Testing ensures that the code runs as expected and therefore has great value.

This article focuses on protecting code by writing more code, but this is not a traditional test, but a custom code checking rule. Recently I came across two articles about custom code checking rules:

• "How to write custom ESLint rules" by Benedict Quinn
• Omri Lavi's "Custom Stylelint Rules - Write Your First Rule"

I mainly use ESLint and Stylelint in the code base. But it should be noted that I found that the custom rules writing process of these two tools is quite complicated. You need to understand the Abstract Syntax Tree (AST). This is completely different from a simple statement like if (rules.find.selector.startsWith("old")) throw("Deprecated selector.")

This reminds me of an interesting question:

Our team is maintaining an old project and hopes to remove many old, problematic CSS selectors. For example, someone opened an HTML file and saw an element with a class named deprecated-selector . Our goal is to have the IDE mark it as code to check for errors and prompt "This is a deprecated selector, please use .ui-fresh\_\_selector instead".

The first thing that comes to mind is to write a custom Stylelint rule that looks for deprecated selectors known to the team and issue warnings. But unfortunately, Stylelint is used to check CSS, and the main problem here seems to be HTML. I know html-inspector can write custom rules, but it's a bit outdated, so I'm not sure if it will succeed.

The above is the detailed content of Writing Your Own Code Rules. For more information, please follow other related articles on the PHP Chinese website!