Sass Style Guide: Ein Sass-Tutorial zum Schreiben von besserem CSS-Code

Das Schreiben von konsistentem und lesbarem CSS, das sich gut skalieren lässt, ist ein herausfordernder Prozess. Vor allem, wenn die Stylesheets immer größer, komplexer und schwieriger zu pflegen sind. Eines der Tools, die Entwicklern zur Verfügung stehen, um besseres CSS zu schreiben, sind Präprozessoren. Ein Präprozessor ist ein Programm, das einen Datentyp nimmt und in einen anderen Datentyp umwandelt, und in unserem Fall sind CSS-Präprozessoren Vorverarbeitungssprachen, die zu CSS kompiliert werden. Es gibt viele CSS-Präprozessoren, die Frontend-Entwickler empfehlen und verwenden, aber in diesem Artikel konzentrieren wir uns auf Sass. Mal sehen, was Sass zu bieten hat, warum es eine bevorzugte Wahl gegenüber anderen CSS-Präprozessoren ist und wie man es am besten einsetzt.

Was ist Sass und warum sollten Sie es verwenden?

Für diejenigen unter Ihnen, die nicht wissen, was Sass ist, besuchen Sie am besten die offizielle Sass-Webseite. Sass ist ein Akronym für Syntactically Awesome StyleSheets und ist eine Erweiterung von CSS, die der Grundsprache Kraft und Eleganz verleiht.

Sass ist ein CSS-Präprozessor mit vielen leistungsstarken Funktionen. Die bemerkenswertesten Funktionen sind Variablen, Erweiterungen und Mixins.

Variablen speichern Informationen, die später wiederverwendet werden können, wie Farben oder andere häufig verwendete Werte. Erweiterungen helfen Ihnen beim Erstellen von „Klassen“, die die Vererbung für die Regeln zulassen. Mixins können Sie sich wie „Funktion“ vorstellen. Sass hat auch einige andere erstaunliche Funktionen im Vergleich zu anderen Präprozessoren, wie die Verwendung von logischen Anweisungen (Bedingungen und Schleifen), benutzerdefinierte Funktionen, die Integration mit anderen Bibliotheken wie Compas und vieles mehr. Allein diese Funktionen können Ihnen und Ihrem Team helfen, produktiver zu sein und am Ende besseres CSS zu schreiben.

Warum Sie einen CSS-Styleguide brauchen

Leider können selbst Präprozessoren nicht alles reparieren und Ihnen helfen, guten CSS-Code zu schreiben. Das Problem, mit dem jeder Entwickler konfrontiert ist, ist, dass aktuelle Webanwendungen immer größer werden. Aus diesem Grund muss Code skalierbar und lesbar sein und Spaghetti-Code und ungenutzte Zeilen davon vermeiden. Um die genannten Probleme zu vermeiden, ist eine Art Standard für Ihr Team in der täglichen Arbeit erforderlich. Was ist Spaghetti-Code und wie entsteht er? Spaghetti-Code ist ein Name für schlechten, langsamen, sich wiederholenden und unlesbaren Code. Wenn ein Team große Anwendungen ohne definierte Richtlinien oder Standards schreibt, schreibt jeder Entwickler, was er braucht und wie er will. Auch wenn Entwickler viele Fehlerbehebungen, Hotfixes und Patches schreiben, neigen sie dazu, Code zu schreiben, der das Problem löst, haben aber keine Zeit, den Code optimal zu schreiben. In solchen Situationen kommt es häufig vor, dass am Ende viele CSS-Zeilen stehen, die in keinem Bereich der Anwendung mehr verwendet werden. Entwickler haben nicht genug Zeit, um den Code zu bereinigen, und sind gezwungen, den Fix so schnell wie möglich zu veröffentlichen. Eine andere wiederkehrende Situation ist, dass Entwickler viel !important verwenden, um kaputte Dinge schnell zu beheben, was zu sehr hackigem Code führt, der schwer zu warten ist, zu vielen unerwarteten Verhaltensweisen führt und später umgestaltet werden muss. Wie bereits erwähnt, wird die Situation mit zunehmendem Code nur noch schlimmer.

Die Idee dieses Artikels ist es, Regeln, Tipps und Best Practices zu teilen, um einen besseren Sass zu schreiben. Die Gruppierung dieser Sass-Tipps und Best Practices kann als Sass-Styleguide verwendet werden. Dieser Styleguide soll Entwicklern helfen, die oben genannten Situationen zu vermeiden. Die Regeln sind zur leichteren Bezugnahme in logische Segmente gruppiert, aber am Ende sollten Sie sie alle übernehmen und befolgen. Oder zumindest die meisten von ihnen.

Gestaltungsrichtlinie

Die Regeln und Best Practices in diesem Styleguide basieren auf der Erfahrung in der Arbeit mit vielen Teams. Einige von ihnen stammen aus dem Trial-by-Error-Verfahren, andere sind von populären Ansätzen wie BEM inspiriert. Für einige Regeln gibt es keinen bestimmten Grund, warum und wie sie festgelegt wurden. Manchmal reicht es aus, die Vergangenheit als einzigen Grund zu haben. Um beispielsweise sicherzustellen, dass der Code lesbar ist, ist es wichtig, dass alle Entwickler den Code auf die gleiche Weise schreiben, daher gibt es die Regel, keine Leerzeichen zwischen Klammern einzuschließen. Wir können darüber streiten, ob es besser ist, das Leerzeichen zwischen Klammern einzuschließen oder nicht. Wenn Sie der Meinung sind, dass Leerzeichen zwischen Klammern besser aussehen, passen Sie diesen Styleguide und die Regeln an Ihre Vorlieben an. Letztendlich besteht das Hauptziel des Styleguides darin, Regeln zu definieren und den Entwicklungsprozess standardisierter zu gestalten.

Allgemeine CSS-Regeln

Allgemeine Regeln sollten immer befolgt werden. Sie konzentrieren sich hauptsächlich darauf, wie Sass-Code formatiert werden sollte, um Konsistenz und Lesbarkeit des Codes zu gewährleisten:

• Verwenden Sie für Einzüge Leerzeichen statt Tabulatoren. Am besten verwenden Sie 2 Leerzeichen. Mit dieser Option können Sie Ihren eigenen heiligen Krieg führen, und Sie können Ihre eigene Regel definieren und entweder Tabulatoren oder Leerzeichen verwenden oder was auch immer Ihnen am besten passt. Es ist nur wichtig, eine Regel zu definieren und diese konsequent zu befolgen.
• Fügen Sie zwischen jeder Anweisung eine Leerzeile ein. Dadurch wird der Code für Menschen besser lesbar, und Code wird von Menschen geschrieben, richtig?
• Verwenden Sie einen Selektor pro Zeile wie folgt:

 selector1, selector2 { }

• Fügen Sie kein Leerzeichen zwischen Klammern ein.

 selector { @include mixin1($size: 4, $color: red); }

• Verwenden Sie einfache Anführungszeichen, um Zeichenfolgen und URLs einzuschließen:

 selector { font-family: 'Roboto', serif; }

• Beenden Sie alle Regeln mit einem Semikolon ohne Leerzeichen davor:

 selector { margin: 10px; }

Regeln für Selektoren

Als nächstes folgen wir mit einer Reihe von Regeln, die beim Umgang mit Selektoren zu verwenden sind:

• Vermeiden Sie die Verwendung von ID-Selektoren. IDs sind zu spezifisch und werden hauptsächlich für JavaScript-Aktionen verwendet.
• Vermeiden Sie !important . Wenn Sie diese Regel verwenden müssen, bedeutet dies, dass mit Ihren CSS-Regeln im Allgemeinen etwas nicht stimmt und dass Ihr CSS nicht gut strukturiert ist. CSS mit vielen !important -Regeln kann leicht missbraucht werden und endet mit unordentlichem und schwer zu wartendem CSS-Code.
• Verwenden Sie keine Kinderauswahl. Diese Regel teilt die gleiche Argumentation wie die ID-Regel. Untergeordnete Selektoren sind zu spezifisch und eng mit Ihrer HTML-Struktur gekoppelt.

Halten Sie Ihre Sass-Regeln in Ordnung

Es ist wichtig, die Konsistenz im Code zu wahren. Eine der Regeln ist, dass Sie die Reihenfolge der Regeln einhalten müssen. Auf diese Weise können andere Entwickler den Code mit viel mehr Verständnis lesen und verbringen weniger Zeit damit, sich zurechtzufinden. Hier die vorgeschlagene Reihenfolge:

1. Verwenden Sie zuerst @extend . Dadurch wissen Sie zunächst, dass diese Klasse Regeln von anderen erbt.
2. Verwenden Sie als nächstes @include . Dass Ihre Mixins und Funktionen ganz oben enthalten sind, ist schön und ermöglicht Ihnen auch zu wissen, was Sie überschreiben werden (falls erforderlich).
3. Jetzt können Sie Ihre regulären CSS-Klassen- oder Elementregeln schreiben.
4. Platzieren Sie verschachtelte Pseudoklassen und Pseudoelemente vor jedem anderen Element.
5. Schreiben Sie schließlich andere verschachtelte Selektoren wie im folgenden Beispiel:

 .homepage { @extend page; @include border-radius(5px); margin-left: 5px; &:after{ content: ''; } a { } ul { } }

Einige Namenskonventionen

Der Teil der Namenskonventionen des Stylebooks basiert auf den beiden bestehenden Namenskonventionen BEM und SMACSS, die unter Entwicklern populär wurden. BEM steht für Block, Element, Modifier. Es wurde vom YANDEX-Team entwickelt, und die Idee hinter BEM war es, Entwicklern zu helfen, die Beziehung zwischen HTML und CSS im Projekt zu verstehen. SMACSS hingegen steht für Scalable and Modular Architecture for CSS. Es ist eine Anleitung zur Strukturierung von CSS, um Wartbarkeit zu ermöglichen.

Inspiriert von ihnen lauten unsere Regeln für Namenskonventionen wie folgt:

• Verwenden Sie Präfix für jeden Elementtyp. Setzen Sie Ihren Blöcken Präfixe wie: Layouts ( l- ), Module ( m- ) und Zustände ( is- ).
• Verwenden Sie für jeden Block zwei Unterstriche für untergeordnete Elemente:

 .m-tab__icon {}

• Verwenden Sie zwei Bindestriche für Modifikatoren für jeden Block:

 .m-tab--borderless {}

Variablen

Verwenden Sie Variablen. Beginnen Sie mit den allgemeineren und globalen Variablen wie Farben und erstellen Sie eine separate Datei für sie _colors.scss . Wenn Sie bemerken, dass Sie einen Wert mehrmals über das Stylesheet wiederholen, gehen Sie und erstellen Sie eine neue Variable für diesen Wert. Bitte TROCKNEN. Sie werden dankbar sein, wenn Sie diesen Wert ändern möchten und wenn Sie ihn nur an einer Stelle ändern müssen.

Verwenden Sie außerdem einen Bindestrich, um Ihre Variablen zu benennen:

 $red : #f44336; $secondary-red :#ebccd1;

Medien-Anfragen

Mit Sass können Sie Ihre Medienabfragen als Elementabfragen schreiben. Die meisten Entwickler schreiben Medienabfragen in eine separate Datei oder am Ende unserer Regeln, aber das wird nicht empfohlen. Mit Sass können Sie Dinge wie das folgende Beispiel schreiben, indem Sie Medienabfragen verschachteln:

 // ScSS .m-block { &:after { @include breakpoint(tablet){ content: ''; width: 100%; } } }

Dies erzeugt ein CSS wie dieses:

 // Generated CSS @media screen and (min-width: 767px) { .m-block:after { content: ''; width: 100%; } }

Mit diesen Regeln für verschachtelte Medienabfragen können Sie sehr genau erkennen, welche Regeln Sie überschreiben, wie Sie im Sass-Snippet sehen können, wo benannte Medienabfragen verwendet werden.

Um benannte Medienabfragen zu erstellen, erstellen Sie Ihr Mixin wie folgt:

 @mixin breakpoint($point) { @if $point == tablet { @media (min-width: 768px) and (max-width: 1024px) { @content; } } @else if $point == phone { @media (max-width: 767px) { @content; } } @else if $point == desktop { @media (min-width: 1025px) { @content; } } }

Weitere Informationen zum Benennen von Medienabfragen finden Sie in den folgenden Artikeln: Medienabfragen benennen und bessere Medienabfragen mit Sass schreiben.

Andere Überlegungen

Am Ende sind hier noch einige andere Überlegungen, die Sie ebenfalls im Hinterkopf behalten und befolgen sollten:

• Schreiben Sie niemals Herstellerpräfixe. Verwenden Sie stattdessen den Autoprefixer.
• Verwenden Sie maximal drei Ebenen tief verschachtelter Regeln. Bei mehr als drei verschachtelten Ebenen ist der Code schwer lesbar, und vielleicht schreiben Sie einen beschissenen Selektor. Am Ende schreiben Sie CSS-Code, um ihn mit Ihrem HTML zu koppeln.

 .class1 { .class2 { li { //last rules } } }

• Schreiben Sie nicht mehr als 50 Zeilen verschachtelten Codes: Oder besser, schreiben Sie nicht mehr als X Zeilen verschachtelten Codes. Richten Sie Ihr eigenes X ein, aber 50 sieht nach einem guten Limit aus. Wenn Sie diese Grenze überschreiten, passt der Codeblock möglicherweise nicht in Ihr Texteditorfenster.
• Schreiben Sie eine Hauptdatei, in die Sie alle Ihre Blöcke, Partials und Konfigurationen importieren.
• Importieren Sie zuerst Anbieter- und globale Abhängigkeiten, dann erstellte Abhängigkeiten, dann Layouts, Muster und schließlich die Teile und Blöcke. Dies ist wichtig, um Mischimporte und das Überschreiben von Regeln zu vermeiden, da die Hersteller- und globalen Regeln nicht von uns verwaltet werden können.
• Seien Sie nicht schüchtern und zerlegen Sie Ihren Code in so viele Dateien wie möglich.

Fazit

Die Idee hinter diesem Styleguide ist es, Ihnen einige Ratschläge zu geben, wie Sie die Art und Weise, wie Sie Ihren Sass-Code schreiben, verbessern können. Bitte denken Sie daran, dass die bereitgestellten Tipps und Regeln in diesem Styleguide auch dann gelten, wenn Sie Sass nicht verwenden, und es wird empfohlen, sie zu befolgen, wenn Sie Vanilla CSS oder einen anderen Präprozessor verwenden. Nochmals: Wenn Sie mit einer der Regeln nicht einverstanden sind, ändern Sie die Regel so, dass sie Ihrer Denkweise entspricht. Am Ende liegt es an Ihnen und Ihrem Team, diesen Styleguide entweder anzupassen, einen anderen Styleguide zu verwenden oder einen komplett neuen zu erstellen. Definieren Sie einfach den Leitfaden und beginnen Sie mit dem Schreiben eines großartigen Codes.