独自のコードルールを書く

プロジェクト開発が特定の段階に達すると、コード保護メカニズムの構築にリソースを投資する必要があります。この機会は、プロジェクトが長い間安定して実行される前に正確に定義することは困難ですが、いくつかの問題が現れ始めますが、まだ完全にはありません。時期尚早の最適化を避け、また、遅すぎる最適化を避けてください。

一部のツールは非常に簡単に実装でき、通常はプロジェクトの初期に入手できます。たとえば、きれいなコードフォーマットツールは、コード仕様をリアルタイムで維持できます。また、アクセシビリティ、互換性、セキュリティコードチェックなど、エンコードプロセス中に直接使用できる多くの同様のツールもあります。 Webhintは、このようなツールを多数統合しますが、試してみる価値があります。

コードを保護するために、より多くのコードを記述する必要があるツールもあります。テストはその重要な部分であり、エンコード中に実行するように設定することさえできます。テストにより、コードが期待どおりに実行されることを保証し、したがって大きな価値があります。

この記事では、より多くのコードを書くことでコードの保護に焦点を当てていますが、これは従来のテストではなく、カスタムコードチェックルールです。最近、カスタムコードチェックルールに関する2つの記事に出会いました。

• Benedict Quinnによる「カスタムEslintルールの書き方」
• Omri Laviの「カスタムStyleLintルール - 最初のルールを書く」

私は主にコードベースでESLINTとSTYLELINTを使用しています。しかし、これら2つのツールのカスタムルールの書き込みプロセスが非常に複雑であることがわかったことに注意する必要があります。抽象的な構文ツリー（AST）を理解する必要があります。これはif (rules.find.selector.startsWith("old")) throw("Deprecated selector.")のような単純なステートメントとはまったく異なります。

これは興味深い質問を思い出させます：

私たちのチームは古いプロジェクトを維持しており、多くの古い、問題のあるCSSセレクターを削除したいと考えています。たとえば、誰かがhtmlファイルを開き、 deprecated-selectorという名前のクラスを持つ要素を見まし.ui-fresh\_\_selector 。

最初に思い浮かぶのは、チームに知られている非推奨セレクターを探して警告を発するカスタムStylelintルールを書くことです。しかし、残念ながら、StyleLintはCSSを確認するために使用されており、ここでの主な問題はHTMLのようです。 HTML-Inspectorがカスタムルールを書くことができることは知っていますが、それは少し時代遅れなので、成功するかどうかはわかりません。

以上が独自のコードルールを書くの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。