Schreiben Sie Ihre eigenen Coderegeln

Wenn die Projektentwicklung eine bestimmte Phase erreicht, müssen Ressourcen in den Aufbau eines Codeschutzmechanismus investiert werden. Diese Gelegenheit ist schwer genau zu definieren. Es dauert ungefähr, bevor das Projekt lange stabil läuft und einige Probleme beginnen, aber es ist noch nicht vollständig im Chaos. Vermeiden Sie eine vorzeitige Optimierung und vermeiden Sie auch eine zu späte Optimierung.

Einige Tools sind sehr einfach zu implementieren und sind normalerweise zu Beginn des Projekts erhältlich. Zum Beispiel kann das schönere Code -Format -Tool die Codespezifikationen in Echtzeit verwalten. Es gibt auch viele ähnliche Tools, die während des Codierungsprozesses direkt verwendet werden können, wie z. B. Zugänglichkeit, Kompatibilität, Sicherheitscodeprüfung usw. WebHint integriert eine große Anzahl solcher Tools, was einen Versuch wert ist.

Es gibt auch Tools, die mehr Code schreiben müssen, um Ihren Code zu schützen. Testen sind ein wichtiger Teil davon und können sogar während der Codierung ausgeführt werden. Tests stellt sicher, dass der Code wie erwartet ausgeführt wird und daher einen großen Wert hat.

Dieser Artikel konzentriert sich auf den Schutz von Code, indem Sie mehr Code schreiben. Dies ist jedoch kein herkömmlicher Test, sondern eine benutzerdefinierte Codeprüfregel. Kürzlich bin ich auf zwei Artikel über benutzerdefinierte Regeln für die Überprüfung des Codes gestoßen:

• "So schreiben Sie benutzerdefinierte Eslint -Regeln" von Benedict Quinn
• Omri Lavis "benutzerdefinierte Stylelint -Regeln - schreiben Sie Ihre erste Regel"

Ich verwende es hauptsächlich Eslint und Stylelint in der Codebasis. Es ist jedoch zu beachten, dass ich festgestellt habe, dass der kundenspezifische Regeln des Schreibens dieser beiden Tools ziemlich kompliziert ist. Sie müssen den abstrakten Syntaxbaum (AST) verstehen. Dies unterscheidet sich völlig von einer einfachen Aussage wie if (rules.find.selector.startsWith("old")) throw("Deprecated selector.")

Dies erinnert mich an eine interessante Frage:

Unser Team unterhält ein altes Projekt und hofft, viele alte, problematische CSS -Selektoren zu entfernen. Zum Beispiel hat jemand eine HTML-Datei geöffnet und ein Element mit einer Klasse namens deprecated-selector gesehen. Unser Ziel ist es, die IDE als Code als Code zu markieren, um auf Fehler zu prüfen und zu fordern. "Dies ist ein .ui-fresh\_\_selector Selektor, bitte verwenden Sie.

Das erste, was mir in den Sinn kommt, ist, eine benutzerdefinierte Stylelint -Regel zu schreiben, die nach veralteten Selektoren sucht, die dem Team bekannt sind und Warnungen ausstellen. Leider wird Stylelint verwendet, um CSS zu überprüfen, und das Hauptproblem hier scheint HTML zu sein. Ich weiß, dass HTML-Inspektor benutzerdefinierte Regeln schreiben kann, aber es ist etwas veraltet, also bin ich mir nicht sicher, ob es erfolgreich sein wird.

Das obige ist der detaillierte Inhalt vonSchreiben Sie Ihre eigenen Coderegeln. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!