SASS Style Programmierhandbuch für CSS

Da immer mehr Entwickler SASS verwenden, müssen wir auf die Anzahl der SASS-Codes achten. Wir können mit der Syntax von CSS (Cascading Style Sheets) beginnen, um einige der Besonderheiten der SASS-Syntax zu erklären. Schließlich sind CSS-Styleguides weit verbreitet.

In diesem Artikel werden hauptsächlich einige Funktionen vorgestellt, die mich persönlich interessieren. Vielleicht können Sie davon profitieren und Ihre eigenen Richtlinien zur SASS-Nutzung erstellen.
Befolgen Sie weiterhin Ihre üblichen CSS-Formatierungsregeln und Stilrichtlinien.

Dieser Artikel konzentriert sich auf einige Inhalte zu SASS, aber auf dieser Grundlage sollten Entwickler ihre bestehenden und guten Formatierungsregeln beibehalten. Wenn Sie noch keinen eigenen Satz Formatierungsregeln entwickelt haben, finden Sie hier eine Zusammenfassung einiger Stilhandbücher, die Ihnen bei der Entwicklung Ihrer eigenen CSS-Schreibgewohnheiten helfen sollten. Dies ist nur ein Teil des Lieferumfangs:

1. Zeileneinzüge konsistent halten
2. Achten Sie auf eine konsistente Anzahl von Leerzeichen vor und nach Doppelpunkten/geschwungenen Klammern
3. Behalten Sie einen Selektor pro Zeile und eine Regel pro Zeile bei
4. Versuchen Sie, verwandte Attribute zusammen zu schreiben
5. Es gibt einen Plan für Klassenbenennungsregeln
6. Vermeiden Sie die Verwendung von CSS-ID-Selektoren
7. Warten

Als nächstes lernen wir, wie man schönen SASS-Code schreibt. Nehmen wir als Beispiel das Schreiben einer Eigenschaft der Klasse .weather:
@extend(s) zuerst auflisten

Auf diese Weise können Entwickler einen klaren Kopf bewahren, die Beziehung zwischen dieser Klasse und ihren Attributen sowie anderen Klassen und deren Attributen sofort verstehen und die Konsistenz der Attribute und klare Ideen für die Wiederverwendung von Attributen aufrechterhalten.
Normaler Stil

Auf diese Weise können Entwickler die Bereitstellung von @extend(s) und @include(s) auf einen Blick erkennen, was ihnen und anderen Entwicklern die Interpretation des Codes erleichtert. Sie können auch entscheiden, ob in einigen Fällen zwischen benutzerdefinierten @includes und @includes aus öffentlichen Quellen unterschieden werden soll (insbesondere im Hinblick auf die Wiederverwendbarkeit und Aktualität des Codes).
Selektor-Verschachtelung

Verwenden Sie innerhalb des verschachtelten Abschnitts weiterhin die oben beschriebenen Stilregeln. Verschachtelte Abschnitte sollten immer zuletzt kommen.
Alle Anbieterpräfixe verwenden @mixins

Herstellerpräfixe (CSS-Präfixe) sind sehr zeitkritisch. Mit der Aktualisierung moderner Browser werden diese Präfixe immer seltener verwendet. Sie können sich an diese Änderungen anpassen, indem Sie den Inhalt Ihrer Mixins aktualisieren (oder einige in Ihren Mixins verwendete Bibliotheken werden automatisch aktualisiert). Es spielt keine Rolle, ob der Mixin nur eine Zeile lang ist.
Wenn jedoch einige Herstellerpräfixe stark privatisiert werden, wird es sehr schwierig sein, diese Präfixe zu standardisieren, und die Anwendung anderer Präfixe oder Versionen ohne Präfix wird den Aufwand nicht wert sein. Ich werde mich dafür entscheiden, @mixin diesen Herstellerpräfixen den Rücken zu kehren. Zum Beispiel -webkit-line-clamp, -mscontent-zoom-chaining oder ähnliches.
Die Verschachtelungsebene sollte 3 Ebenen nicht überschreiten.

Bei mehr als dreimaliger Verschachtelung besteht eine hohe Wahrscheinlichkeit, dass Sie einen fehlerhaften (schlechten?) Selektor geschrieben haben. Die Gründe für diesen Fehler liegen darin, dass der Selektor zu stark von der HTML-Architektur abhängig (instabil), zu detailliert (zu leistungsfähig und unflexibel) oder zu schwierig wiederverwendbar (nicht sehr verwendbar) ist. Gleichzeitig können zu viele verschachtelte Ebenen dazu führen, dass der Code undurchsichtig und schwer verständlich wird.

Manchmal gibt es so viel klassenbezogenen Code, dass Sie Tag-Selektoren verwenden müssen. Um eine unnötige Kaskadierung zu vermeiden, müssen Sie möglicherweise sehr genau angeben, was Sie für eine Klasse schreiben. Es ist sogar möglich, „extend“ zu verwenden, um einige der Wiederverwendbarkeitsfunktionen in CSS zu nutzen.

Die Anzahl des verschachtelten Codes sollte 50 Zeilen nicht überschreiten.

Wenn die Verschachtelung in SASS 50 Zeilen überschreitet, kann sie möglicherweise nicht vollständig auf einer Seite des Compilers angezeigt werden, was das Lesen und Verstehen des Codes erschwert. Die Verschachtelung sollte ursprünglich das Denken und die Code-Organisation erleichtern und vereinfachen. Wenn es die Lesbarkeit beeinträchtigt, verzichten Sie bitte auf die Verschachtelung.
Globale und lokalisierte SASS-Dateisequenzen entsprechen Tabelleninhalten

Mit anderen Worten: Sie haben keinen festen Stil. Entwickler sollten daran denken, den Stil aller Teile konsistent und geordnet zu halten.

Zuerst werden die Anbieter-/globalen Bibliotheken aufgelistet, gefolgt von den benutzerdefinierten Bibliotheken, dann den Modi und schließlich den von jeder Abteilung verwendeten Bibliotheken.

Somit sieht das „Verzeichnis“ wie im folgenden Beispiel aus, was auf den ersten Blick sehr übersichtlich ist:

Diese Dateien sind wie ein Kompass, Farben und Mixins generieren keinen kompilierten CSS-Code, sie sind rein unabhängige Bibliotheken. Danach wurden Muster eingeführt, um das Umschreiben sicherer zu machen, ohne dass es zu Exklusivitätskonflikten kommt.
Teilen Sie SASS in mehrere kleine Dateien auf

Es ist nichts falsch daran, dies zu tun. Verwenden Sie nach Möglichkeit mehrere kleine und präzise Dateien. So können Entwickler bestimmte Dateien leichter finden, anstatt in mehreren großen Dateien mit langem Code nach der Nadel im Heuhaufen zu suchen.

...

Was ich häufig mache, ist, diese Dateien einzeln in einer globalen SCSS-Datei zu referenzieren, anstatt auf eine _header.scss-Datei zu verweisen und sie dann einzeln in der _header.scss-Datei zu referenzieren. Dadurch kann die Indizierungszeit verkürzt und die Leseleistung verbessert werden.

Wenn zu viele dieser Dateien vorhanden sind und die Importsequenz zu lang ist, möchten Sie möglicherweise Globbing verwenden.
Denken Sie daran, die Partials als _partial.scss zu benennen

Dies ist eine gängige Namenskonvention für Dateien, die sich nicht selbst kompilieren. Solche Dateien sind mehr oder weniger von anderen Dateien abhängig, sodass eine unabhängige Kompilierung nicht möglich ist. Ich persönlich füge gerne einen Unterstrich vor dem Dateinamen hinzu, z. B. _dropdown-menu.scss
Zeilenzuordnung beim lokalen Kompilieren hinzufügen

Sehen Sie, das bedeutet, dass die Entwicklungstools Ihnen die Quelle jeder Regel mitteilen können, auch wenn es sich um eine importierte Teildatei handelt.
Denken Sie beim Bereitstellen daran, die minimierten Dateien zu kompilieren

Eine funktionierende Webseite sollte immer nur minimales CSS verwenden.
Keine Notwendigkeit, .css-Dateien einzureichen

Dies kann einige Zeit dauern, aber es kann wunderbar sein, keine CSS-Dateien in Ihrem Repository zu haben. Die Kompilierung erfolgt zum Bereitstellungszeitpunkt. Das Einzige, was Sie sehen können, sind die schön formatierten, minimierten Sass-Dateien. Dies macht die Beschreibung der Datei sehr nützlich. Dateibeschreibungen werden verwendet, um vom Versionsherausgeber vorgenommene Änderungen zu vergleichen. Für die bereits vereinfachten CSS-Dateien wird die Dateibeschreibung grundsätzlich nicht benötigt.
Großzügige Nutzungshinweise

Nur wenige Leute bereuen, Kommentare in ihrem Code hinterlassen zu haben. Unabhängig davon, ob sie nützlich oder unbedeutend sind, werden Kommentare beim Kompilieren in minimierte CSS-Dateien letztendlich gelöscht, ohne dass dem Entwickler zusätzliche Kosten entstehen.

.overlay {
/* Es gibt 6000 Modale, 5500 Speichermeldungen und 2000 Header */
Z-Index: 5000;
}

Apropos Kommentare: Möglicherweise möchten Sie auch hier einige Standardisierungsanpassungen vornehmen. In SASS eignet sich „//“ sehr gut zum Hinzufügen von Kommentaren. „//“ macht das Kommentieren und Aufheben von Kommentaren sehr bequem.
Konvertieren Sie einige häufig verwendete Werte und Werte mit besonderer Bedeutung in Variablen

Wenn Sie einen Wert wiederverwenden (was im Front-End-Design sehr häufig vorkommt), sollten Sie ihn besser in eine Variable umwandeln. Auf diese Weise können Sie sich durch die Benennung an die Bedeutung des Wertes erinnern und beim Schreiben von Code konsistent bleiben, sodass Sie ihn beim Ändern des Werts nicht zeilenweise anpassen müssen.

Wenn eine Zahl eine eindeutige Bedeutung hat, ist die Umwandlung in eine Variable unabdingbar.

Diese Zahlen können in einer einzigen Datei gespeichert und als @imported importiert werden. Auf diese Weise können Sie alle Z-Index- oder anderen Variablen einheitlich verwalten
Farben in Variablen umwandeln

Außer Schwarz und Weiß. Viele Farben werden mehr als nur einmal verwendet, auch wenn Sie meinen, sie nicht noch einmal zu verwenden. Wenn Sie es jedoch in eine Variable umwandeln, stellen Sie möglicherweise fest, dass Sie es an anderen Stellen benötigen. Für Farbvariablen gibt es in Sass Farbfunktionen, die diese verarbeiten können, wie etwa lighten() und darkern(). Dies erleichtert die Kontrolle der Gesamtfarbe (einmal ändern und vergessen)
Verschachteln und benennen Sie Ihre Medienbibliotheken

Die Möglichkeit, Medienbibliotheken in Sass zu verschachteln, bedeutet 1. dass Sie Selektoren nicht woanders überschreiben und dadurch unnötige Fehler verursachen müssen; 2. dass klar ist, welche Regeln Sie überschreiben, was sehr verwirrend sein kann, wenn dies am Ende Ihres CSS oder in einer anderen Datei steht.

Eine ausführlichere Erklärung finden Sie hier: http://css-tricks.com/naming-media-queries/
Scham an letzte Stelle setzen

Importieren Sie in Ihr globales Stylesheet am Ende eine _shame.scss-Datei.

Wenn Sie schnell einige Änderungen vornehmen müssen, können Sie dies hier tun. Wenn Sie später Zeit und Energie haben, können Sie
Die an der Gesamtarchitektur in _shame.scss vorgenommenen Änderungen sind besser organisiert und strukturiert. Weitere Einzelheiten finden Sie unter: http://csswizardry.com/2013/04/shame-css/
Du bist derjenige, der alles entscheidet

Sass tut nichts, was Sie ihm nicht sagen, daher liegt die endgültige Ausgabe Ihrer Sass-Datei bei Ihnen. Das Schreiben von CSS-Dateien mit Sass ist genau wie das Schreiben von CSS-Dateien ohne Sass. Sie sind der Meister des Codes.