Cleverer Code

Diese Woche untersuchte Chris Ferdinandi einen cleveren JavaScript-Snippet, der kreativ mit neuen Syntaxfunktionen geschrieben ist, aber vielleicht weniger lesbar und performant ist. Es ist eine schnelle Lektüre, aber sein Aufruf an die Fixierung unserer Branche auf Cleverness ist es wert... herauszugreifen.

...wir sind als Branche besessen von Kürze und cleverem Code, und das Ergebnis ist Code, der manchmal weniger performant und für die meisten Menschen typischerweise schwerer zu lesen und zu verstehen ist.

Er argumentierte letzte Woche ähnlich, als er über Code-Lesbarkeit schrieb, und bemerkte, dass Kürze cool aussehen mag, aber letztendlich zu allen möglichen Problemen in einer Codebasis führt.

Oft sind Webentwickler von Kürze besessen. Es gibt diese Sache, bei der Entwickler versuchen, dieselbe Funktion mit möglichst wenigen Zeichen zu schreiben.

Persönlich halte ich Kürze für sinnlos. Lesbarkeit ist viel wichtiger.

Ich stimme Chris in diesem Punkt vollkommen zu, aber ich denke, es gibt eine wichtige Unterscheidung zu treffen, und das ist der Unterschied zwischen Code, der als Prototyp gedacht ist, und Code, der für die Produktion gedacht ist. Wie Jeremy Keith vor einiger Zeit argumentierte:

Interessant ist, dass – wenn es um Prototyping geht – unsere üblichen Frontend-Prioritäten über Bord gehen können und sollten. Die Priorität ist jetzt Geschwindigkeit. Wenn das bedeutet, Semantik oder Leistung zu opfern, dann sei es so. Wenn ich einen Prototypen baue und mich frage: „Nun, was ist der richtige Klassenname für diese Komponente?“, dann weiß ich, dass ich in der falschen Denkweise bin. Diese Frage mag für Produktionscode gültig sein, aber für Prototypen ist sie Zeitverschwendung.

Ich stimme Chris zu, dass wir Code schreiben sollten, der leicht zu lesen ist, wenn wir in der Produktion sind. Ich denke auch, dass das Experimentieren mit Code auf diese Weise gut ist, wenn es um Prototypen geht. Wir sollten niemals davor zurückschrecken, mit Code zu spielen und Dinge ein wenig voranzutreiben – solange wir das nicht in einer riesigen Web-App tun, in der viele andere Entwickler mit uns zusammenarbeiten.

---

Ich habe festgestellt, dass einige Leute wirklich geniale Dinge mit Sass machen. Ich sitze regelmäßig da und denke: „Wow, so etwas habe ich noch nie gesehen.“ Aber wenn es um eine Web-Produktions-App geht, die von Hunderten von Menschen gleichzeitig verstanden werden muss, glaube ich nicht, dass dies die Reaktion ist, die wir wollen, wenn jemand den Code ansieht.

Daher versuche ich, Sass-Code zu schreiben, der tatsächlich so einfach ist, dass er fast dumm aussieht. Eine einfache Möglichkeit, Code viel einfacher zu machen, ist die Reduzierung der Verschachtelung.

.element {
  .heading { ... }
}

Das sieht gut aus, wenn Code darin ist – und es ist ziemlich leicht zu verstehen – aber fügen Sie ein komplexes Design hinzu (sagen wir, mit Pseudo-Elementen und Media Queries) und Sie haben plötzlich einen ziemlich komplexen Regelsatz vor sich. Kreativität und Cleverness können schwerer zu scannen und einen kleinen Teil des Codes zu identifizieren sein, den Sie suchen. Außerdem haben wir in diesem Beispiel unsere .heading Klasse unnötigerweise etwas spezifischer gemacht, was uns ermutigen könnte, Dinge an anderer Stelle in der Codebasis auf eine ungeschickte Weise zu überschreiben.

Wir könnten Folgendes schreiben:

.element { ... }

.element-heading { ... }

Ich weiß, das sieht albern einfach aus, aber die Beziehung zwischen diesen beiden Klassen ist leichter zu erkennen und in Zukunft leichter zu erweitern. Das Bündeln all dieses Codes in eine einzige verschachtelte Klasse kann sehr schnell aus dem Ruder laufen. Auch wenn es viel cooler aussieht.

(Nebenbei bemerkt, Andy Bells Beitrag über die Verwendung des kaufmännischen Und in Sass – und die daraus resultierenden Kommentare – ist ein großartiges Beispiel für den Konflikt zwischen Kreativität und Praktikabilität.)

Jedenfalls ist der Punkt, den ich hier machen möchte, dass CSS (und übrigens auch JavaScript) eine seltsame Sprache ist, weil es keine festen Regeln dafür gibt. Es hängt alles vom Codebase und dem Projekt ab. Aber ich denke, wir können sicher sagen, dass unser Code viel langweiliger sein sollte als unsere Prototypen, wenn sie in Produktion gehen.

Machen Sie weiterhin Prototypen, die wild und experimentell oder unmöglich seltsam sind! Codequalität verdammt.