Durchsetzung von CSS-Syntax-Stil (und mehr!)

Ich wette, Sie haben einen Stil, in dem Sie größtenteils CSS schreiben. Sie mögen zum Beispiel 4 Leerzeichen. Sie haben immer ein Leerzeichen nach geschweiften Klammern und Doppelpunkten. Sie setzen immer ein Leerzeichen nach Regeldefinitionen. Sie schreiben nur eine Deklaration pro Zeile, und die einzigen Deklarationen, die mehrzeilig sein können, sind, wenn es sich um große Blöcke wie einen Verlauf oder eine durch Kommas getrennte Eigenschaft `box-shadow` handelt.

Sie könnten dies noch weiter treiben und es kodifizieren. Vielleicht haben Sie eine Teambesprechung dazu und entscheiden, wie Sie Code stylen möchten. Sie erstellen eine Anleitung und stellen sie jedem im Team zur Verfügung.

Sauberer Code ist wichtig, sagen Sie. Während Stilunterschiede im Code keine Rolle für die endgültige Ausgabe spielen (die meisten von uns haben Build-Prozesse, die den Code ohnehin komprimieren), ist er für die tägliche Arbeit wichtig. Eine unordentliche, inkonsistente Codebasis ist schwer anzusehen und schwer zu verstehen. Wenn man in sauberen Code eintaucht, kann man sich schneller auf die richtige Denkweise einstellen und an der Aufgabe arbeiten, anstatt frustriert vom Durcheinander zu sein.

Harry Roberts nannte dies kürzlich sogar einen Lackmustest für Entwickler

[Aufgeräumter Code] scheint etwas sehr Oberflächliches zu sein, worüber man sich Sorgen machen muss, aber meiner Meinung nach signalisiert aufgeräumter Code etwas Wichtigeres: Ich würde annehmen, dass ein ordentlicher Entwickler mehr Liebe zum Detail hat, eher Prozessen folgt und eher Fehler erkennt. Richtig oder falsch, ich sehe es als Lackmustest für allgemeinere Ansätze und Einstellungen.

Automatisierte Stilprüfung/Warnung

Ein Schritt über die bloße Einigung auf Standards hinaus ist, dass Ihr Computer Ihnen tatsächlich hilft sicherzustellen, dass Sie es richtig machen.

Ich wette, das ist bei JavaScript- oder serverseitigen Programmierern weitaus üblicher. Zum Beispiel ist ESLint sehr beliebt. Sie konfigurieren es mit zahlreichen Regeln basierend darauf, was Ihr Team für gute Syntax hält.

ESLint geht etwas weiter als nur Stilprüfung, da es zum Beispiel weiß, ob Sie eine Funktion verwenden oder nicht, oder versuchen, eine undefinierte Variable zu verwenden. Tools wie Rubocop für Ruby-Code sind ähnlich. Sie können sie für Stilprüfungen verwenden, aber mehr tun.

Stilprüfung muss nicht im Code-Editor selbst stattfinden. Es ist ziemlich nützlich, wenn sie es ist, damit Sie Probleme sofort beheben können, während Sie sie erstellen, aber das muss nicht sein. Für ein großes und technologisch vielfältiges Team ist es möglicherweise praktischer, die Stilprüfung als Teil des Aufgabenlaufs / der Build-Prozess-Einrichtung zu machen.

Zum Beispiel kann ESlint in Grunt oder Gulp integriert werden, sodass Sie beim Verarbeiten von JavaScript-Dateien Fehlerausgaben sehen

Es gibt also mehrere Möglichkeiten, Stilprüfungen zu integrieren

• Innerhalb einer lokalen IDE
• Als Teil eines lokalen Task-Runner-Setups
• Als Teil automatisierter Tests
• Eine Kombination aus diesen

Und Sie können es noch weiter treiben. Zum Beispiel, indem Sie Linting-Fehler wie fehlgeschlagene Tests behandeln und Git-Workflow-Sachen verhindern. Sie können zum Beispiel keine Merge-Anfrage abschließen, bis alles bestanden wurde.

Moment mal! Wir reden hier über CSS!

In der Tat. Soweit ich weiß, ist stylelint hier der große Akteur. David Clark hat letztes Jahr hier auf CSS-Tricks alles darüber geschrieben.

stylelint ist sehr ähnlich wie ESlint. Sie können es auf die gleiche Weise integrieren: als Teil eines Task-Runner-Workflows oder direkt in Ihrem Code-Editor.

Im Moment benutze ich Sublime Text, und hier sehe ich, wie ich stylelint mit SublimeLinter verwende, derselbe Linter-UI, den ich für ESlint benutze

Sie werden wahrscheinlich auch gut damit fahren, mit einer Standardkonfiguration zu beginnen.

Was ist mit meinungsfreudigen CSS-Entscheidungen?

Man könnte sagen, dass stylelint (und ESlint) *nicht meinungsfreudig* sind. Sie sind absichtlich sehr flexibel. Sie können beliebige Regeln einbeziehen (oder Regeln weglassen), und selbst wenn Sie Regeln hinzufügen, sind sie so konzipiert, dass sie flexibel sind, indem sie die Regel entweder auf die eine oder andere Weise erzwingen und sogar Ausnahmen zulassen.

Wichtiger ist, ich würde sie als nicht meinungsfreudig bezeichnen, weil sie Ihren Code nicht wirklich beurteilen. Aber was ist, wenn Sie ein Werkzeug wünschen, das Ihren Code beurteilt?

„Hey, Sie verwenden zu viele Floats!“

„Hey, diese Eigenschaft wird nicht besonders gut unterstützt!“

„Hey, @import ist ziemlich schlecht für die Leistung!“

Das ist eher das Territorium von CSSLint, das eine Vielzahl von ziemlich meinungsfreudigen Regeln hat.

Es gibt sicherlich Überschneidungen. CSSLint kann zum Beispiel nach doppelten Eigenschaften suchen, genau wie stylelint.

Können Sie sie zusammen verwenden? Wahrscheinlich. Sicher, auf der Kommandozeilen- / Task-Runner-Ebene können Sie das tun. Ich bin mir nicht ganz sicher, wie es funktionieren würde, beide gleichzeitig in einen IDE-Linter zu integrieren. Probieren Sie es aus!

Vielleicht hilft ein Vergleich, diesen Teil abzuschließen

• stylelint ist sehr ähnlich wie ESLint (weniger meinungsfreudig)
• CSSLint ist sehr ähnlich wie JSlint (meinungsfreudiger)

Können diese Dinge nicht wirklich automatisiert werden? Wie die Probleme tatsächlich für mich beheben?

Das ist es, was mich überhaupt erst zum Nachdenken über diese Dinge gebracht hat. Ich mag IDE-Linting ziemlich gut, aber ich denke, die Idee der automatischen Behebung von Stilen mag ich noch mehr.

Wir reden hier im Wesentlichen über „Verschönerung“ (auch bekannt als „Code aufräumen“ oder „Schönmachen“).

Der neue, super beliebte Spross für JavaScript ist Prettier, was meiner Meinung nach eine gute Wahl ist. Aber das hilft uns nicht mit CSS.

Es gibt einen weiteren, JS Beautifier, der mit CSS (und HTML!) funktioniert.

CSS Comb ist ein weiteres Werkzeug in dieser Richtung. Es hat weitaus weniger Optionen als stylelint (Ihre Entscheidung, ob das gut oder schlecht ist) und verfügt über einen coolen Konfigurations-Builder zum Festlegen dieser Regeln. CSS Comb sieht ziemlich beliebt und gut gemacht aus, aber ich werde es nicht weiter empfehlen, da es so aussieht, als hätten sie das Projekt aufgegeben

Das Werkzeug wird nicht mehr entwickelt, wir können aber immer noch Parsing-Fehler und kritische Fehler beheben. Das bedeutet, dass Sie keine neuen Funktionen oder Optionen erwarten sollten.

CSS verändert sich heutzutage ziemlich schnell, daher wäre ich nervös, ein Werkzeug zu integrieren, das nicht geändert wird. Eine Art Dämpfer, denn CSS Comb kann einige Dinge tun, die andere nicht können, wie z. B. Eigenschaften neu anordnen, wie Sie es wünschen, was ziemlich cool ist (obwohl es wie immer Optionen gibt).

Es gibt vielleicht eine bessere Option als diese beiden…

stylefmt

Da die beste Wahl für die CSS-Stilprüfung stylelint ist, warum nicht die exakte stylelint-Konfiguration zum tatsächlichen Beheben des CSS verwenden! (Nun, fast exakt.)

Das ist es, was stylefmt tut. Und wie die meisten dieser anderen Werkzeuge, über die wir gesprochen haben, kann es auf Abruf auf IDE-Ebene oder als Teil von Task-Runnern / Build-Prozessen integriert werden.

Hier ist ein Beispiel dafür, wie ich in Sublime Text mit einer SCSS-Datei arbeite, die stylelint-Fehler aufweist und wie diese mit stylefmt behoben werden.

Super.

stylefmt ist nicht die einzige Option, es gibt auch perfectionist.

Zum Abschluss

Stilprüfung ist ziemlich cool. Sie kann nicht nur durchgeführt werden, sondern auch stark an Ihre Bedürfnisse angepasst werden. Sie kann überall in Ihren Prozess integriert werden, wo es für Sie und Ihr Team am besten funktioniert. Für CSS werden Sie mit stylelint gut zurechtkommen. Sie können Probleme sogar automatisch mit Tools wie stylefmt beheben. Sie können auch eine ziemlich gute Abdeckung Ihres gesamten Codebestands erzielen, mit Dingen wie ESLint für JavaScript und Rubocop für Ruby.