CSS Code Smells

Jede Woche (ungefähr) veröffentlichen wir den Newsletter, der die besten Links, Tipps und Tricks rund um Webdesign und -entwicklung enthält. Am Ende schreiben wir normalerweise über etwas, das wir in der Woche gelernt haben. Das muss nicht direkt mit CSS oder Front-End-Entwicklung zu tun haben, aber es macht viel Spaß, es zu teilen. Hier ist ein Beispiel für einen dieser Abschnitte aus dem Newsletter, in dem ich über Codequalität schwafle und darauf eingehe, was meiner Meinung nach ein Code Smells in Bezug auf die CSS-Sprache sein sollte.

---

Viele Entwickler beschweren sich über CSS. Die Kaskade! Die seltsamen Eigenschaftsnamen! Vertikale Ausrichtung! Es gibt viele seltsame Dinge an der Sprache, besonders wenn man mit einer Programmiersprache wie JavaScript oder Ruby vertrauter ist.

Ich denke jedoch, das eigentliche Problem mit der CSS-Sprache ist, dass sie einfach, aber nicht leicht ist. Was ich damit meine, ist, dass es nicht viel Zeit braucht, um CSS zu lernen, aber es außergewöhnlichen Aufwand erfordert, "gutes" CSS zu schreiben. Innerhalb einer Woche oder zwei können Sie wahrscheinlich alle Eigenschaften und Werte auswendig lernen und wirklich schöne Designs im Browser ohne Plugins oder Abhängigkeiten erstellen und all Ihre Freunde beeindrucken. Aber das meine ich nicht mit "gutem CSS".

Um zu definieren, was das ist, denke ich in letzter Zeit viel darüber nach, wie wir zuerst erkennen können, was schlechtes CSS ist. In anderen Bereichen der Programmierung sprechen Entwickler dazu neigen, von Code Smells zu sprechen, wenn sie schlechten Code beschreiben; Hinweise in einem Programm, die darauf hindeuten, dass vielleicht die Sache, die Sie geschrieben haben, keine gute Idee ist. Es könnte etwas Einfaches sein, wie eine Namenskonvention oder ein besonders fragiles Stück Code.

In ähnlicher Weise ist unten meine eigene Liste von Code Smells, die meiner Meinung nach helfen, schlechtes Design und CSS zu identifizieren. Beachten Sie, dass diese Punkte mit meinen Erfahrungen beim Aufbau großer Designsysteme in komplexen Anwendungen zusammenhängen, nehmen Sie dies also bitte mit einer Prise Salz.

Code Smell #1: Die Tatsache, dass Sie überhaupt CSS schreiben

Ein großes Team wird wahrscheinlich bereits über eine Sammlung von Tools und Systemen verfügen, um Dinge wie Buttons oder Stile zu erstellen, um Elemente in einem Layout zu verschieben. Die bloße Tatsache, dass Sie CSS schreiben werden, ist wahrscheinlich eine schlechte Idee. Wenn Sie gerade benutzerdefiniertes CSS für einen bestimmten Sonderfall schreiben wollen, dann hören Sie auf! Sie müssen wahrscheinlich eines der folgenden tun:

1. Lernen Sie, wie das aktuelle System funktioniert und warum es die von ihm vorgegebenen Einschränkungen hat, und halten Sie sich an diese Einschränkungen.
2. Überdenken Sie die zugrundeliegende Infrastruktur des CSS.

Ich denke, dieser Ansatz wurde hier perfekt beschrieben.

Über die falsche Geschwindigkeit von "schnellen Lösungen". pic.twitter.com/91jauLyEJ3

- Pete Lacey (@chopeh) 2. November 2017

Code Smell #2: Dateinamen und Namenskonventionen

Nehmen wir an, Sie müssen eine Support-Seite für Ihre App erstellen. Als Erstes erstellen Sie wahrscheinlich eine CSS-Datei namens `support.scss` und beginnen, Code wie diesen zu schreiben.

.support {
  background-color: #efefef;
  max-width: 600px;
  border: 2px solid #bbb;
}

Das Problem hier sind also nicht unbedingt die Stile selbst, sondern das Konzept einer "Support-Seite" an sich. Wenn wir CSS schreiben, müssen wir in viel größeren Abstraktionen denken — wir müssen an Vorlagen oder Komponenten denken und nicht an die spezifischen Inhalte, die der Benutzer auf einer Seite sehen muss. Auf diese Weise können wir etwas wie eine "Karte" immer wieder auf jeder Seite wiederverwenden, einschließlich der einen Instanz, die wir für die Support-Seite benötigen.

.card {
  background-color: #efefef;
  max-width: 600px;
  border: 2px solid #bbb;
}

Das ist schon etwas besser! (Meine nächste Frage wäre: Was ist eine Karte, welche Inhalte kann eine Karte enthalten, wann ist es in Ordnung, eine Karte zu verwenden, usw. usw. – diese Fragen werden das Design wahrscheinlich hinterfragen und Sie fokussiert halten.)

Code Smell #3: HTML-Elemente stylen

Meiner Erfahrung nach bedeutet das Stylen eines HTML-Elements (wie ein Section- oder Paragraph-Tag) fast immer, dass wir einen Hack schreiben. Es gibt nur einen geeigneten Zeitpunkt, ein HTML-Element direkt so zu stylen.

section { display: block; }
figure { margin-bottom: 20px; }

Und das sind die globalen, sogenannten „Reset Styles“ der Anwendungen. Andernfalls machen wir unseren Codebase fragmentiert und schwieriger zu debuggen, da wir keine Ahnung haben, ob diese Stile Hacks für einen bestimmten Zweck sind oder ob sie die Standardwerte für dieses HTML-Element definieren.

Code Smell #4: Code einrücken

Das Einrücken von Sass-Code, sodass sich Kindkomponenten innerhalb eines Elternelements befinden, ist fast immer ein Code Smell und ein sicheres Zeichen dafür, dass dieses Design refaktorisiert werden muss. Hier ist ein Beispiel.

.card {
  display: flex;
  
  .header {
    font-size: 21px;
  }
}

Sagen wir in diesem Beispiel, dass Sie eine `.header`-Klasse nur innerhalb einer `.card` verwenden können? Oder überschreiben wir einen anderen CSS-Block irgendwo tief in unserer Codebase? Die Tatsache, dass wir überhaupt solche Fragen stellen müssen, zeigt das größte Problem hier: Wir haben nun Zweifel in die Codebase gesät. Um wirklich zu verstehen, wie dieser Code funktioniert, muss ich Kenntnis von anderen Code-Teilen haben. Und wenn ich Fragen stellen muss, warum dieser Code existiert oder wie er funktioniert, dann ist er wahrscheinlich entweder zu kompliziert oder zukünftig nicht wartbar.

Dies führt zum fünften Code Smell…

Code Smell #5: CSS überschreiben

In einer idealen Welt haben wir eine Reset-CSS-Datei, die alle unsere Standardelemente stylt, und dann haben wir separate, einzelne CSS-Dateien für jeden Button, jeden Formularinput und jede Komponente in unserer Anwendung. Unser Code sollte höchstens einmal durch die Kaskade überschrieben werden. Erstens macht dies unseren gesamten Code vorhersehbarer und zweitens macht es unseren Komponenten-Code (wie `button.scss`) super lesbar. Wir wissen jetzt, dass wir, wenn wir etwas reparieren müssen, eine einzelne Datei öffnen können und diese Änderungen mit einem Schlag in der gesamten Anwendung repliziert werden. Wenn es um CSS geht, ist Vorhersehbarkeit alles.

In derselben CSS-Utopie würden wir dann vielleicht bestimmte Klassennamen mit etwas wie CSS Modules unmöglich zu überschreiben machen. So können wir keine Fehler versehentlich machen.

Code Smell #6: CSS-Dateien mit mehr als 50 Zeilen Code

Je mehr CSS Sie schreiben, desto komplizierter und fragiler wird die Codebase. Wenn ich also ungefähr 50 Zeilen CSS erreiche, überdenke ich normalerweise, was ich entwerfe, indem ich mir ein paar Fragen stelle. Beginnend und endend mit: "Ist dies eine einzelne Komponente oder können wir sie in separate Teile aufteilen, die unabhängig voneinander arbeiten?"

Das ist ein schwieriger und zeitaufwändiger Prozess, der endlos geübt werden muss, aber er führt zu einer soliden Codebase und trainiert Sie, wirklich gutes CSS zu schreiben.

Zusammenfassung

Ich nehme an, ich habe jetzt eine weitere Frage, diesmal an Sie: Was betrachten Sie als Code Smell in CSS? Was ist schlechtes CSS? Was ist wirklich gutes CSS? Hinterlassen Sie unbedingt einen Kommentar unten!