Bei der Arbeit an einem Artikel über nutzerzentrierte Webentwicklung habe ich mich etwas eingehender mit dem Thema Konsistenz im Code beschäftigt. Konsistenz ist einer der Hauptgründe, warum wir Codierungsrichtlinien benötigen, und auch ein Faktor für Codequalität. Interessanterweise, so habe ich festgestellt, gibt es drei Ebenen der Konsistenz: individuell, kollektiv und institutionell.
Ebene 1: Individuelle Konsistenz
Auf einer grundlegenden Ebene, wenn es in unserer Organisation wenig Standardisierung gibt (oder wenn wir einfach alleine arbeiten), bedeutet Konsistenz einfach, mit uns selbst konsistent zu sein. Wir profitieren davon, Code immer auf die gleiche Weise zu formatieren.
Wenn wir, jeder für sich, normalerweise unnötige Anführungszeichen um Attributwerte weglassen, was absolut zulässig ist, wie solche Projekte beweisen, sollten wir dies *immer* tun. Wenn wir es vorziehen, die letzte Deklaration in einer CSS-Regel nicht mit einem Semikolon zu beenden, sollten wir dies *niemals* tun. Wenn wir es vorziehen, immer Tabs zu verwenden, sollten wir dies *immer* tun.
Ebene 2: Kollektive Konsistenz
Auf der nächsten Ebene, und hier gehen wir davon aus, dass es Code von anderen Entwicklern oder Drittanbietern gibt, bedeutet Konsistenz, den verwendeten Code-Stil zu befolgen, wann immer wir Code anfassen. Wir sollten den Code-Stil, der in den Dateien vorherrscht, die wir anfassen, respektieren und ihm konsistent folgen.
Wenn wir unserem Kollegen beim Starten einer Website helfen und deren CSS anpassen, formatieren wir den Code so, wie er es getan hat. Wenn wir einige Kern-Dateien unseres Content-Management-Systems anpassen (falls das ratsam wäre), tun wir, was sie tun. Wenn wir ein neues Plugin für etwas schreiben, tun wir es so, wie andere Plugins geschrieben sind.
Ebene 3: Institutionelle Konsistenz
Schließlich, normalerweise auf einer Ebene, die in größeren Organisationen erreicht wird, bedeutet Konsistenz die Einhaltung (oder erstmalige Erstellung) der Codierungsrichtlinien und Styleguides der Organisation. Wenn die Richtlinien gut etabliert und gut durchgesetzt sind, bietet diese Art von Konsistenz die größte Macht, um auch Verhaltensänderungen zu bewirken – individuelle Konsistenz bietet dafür fast keinen Anreiz, kollektive Konsistenz nur vorübergehend.
Wenn wir normalerweise mit Leerzeichen einrücken und der Corp Styleguide Tabs vorgibt, verwenden wir Tabs. Wenn unsere Kollegen ihr Mini-Projekt starten und wir beim Helfen ihren Code entdecken, der nicht den Unternehmensrichtlinien entspricht, nehmen wir uns die Zeit, ihn zu refaktorisieren. Wenn wir etwas Neues beginnen, vielleicht basierend auf einer anderen Sprache, starten wir einen Prozess zur Einrichtung von Richtlinien und zur Standardisierung.
Diese Konsistenzebenen sind nicht gegenseitig ausschließend
In unseren eigenen Angelegenheiten sollten wir zumindest nach Ebene 1 streben, aber persönlich habe ich großartige Erfahrungen damit gemacht, mich an einen externen Standard der Ebene 3 zu halten (ich folge Googles HTML/CSS-Richtlinien mit der einzigen Ausnahme der Verwendung von Tabs anstelle von Leerzeichen) und einen komplementären Standard im Stil der Ebene 1 detailliert zu definieren (wie mit einer vordefinierten Selector-Reihenfolge).
Wenn wir mit anderen Entwicklern zu tun haben, aber nur, wenn es keinen breiteren Standard gibt, sollten wir zumindest auf Konsistenz der Ebene 2 abzielen, das heißt, ihren Code respektieren. Wir fassen etwas in ihrem Bereich an, wir schreiben es so, wie sie es tun würden.
Wenn wir in einer größeren Organisation sind – wobei „größer“ wirklich schon ab zwei Personen beginnen kann –, gilt diese gleiche Idee der Konsistenz der Ebene 2, aber wir können jetzt darüber nachdenken, Standards für die Arbeit auf Ebene 3 einzurichten. Dort können wir sogar die beiden Ebenen verschmelzen: Folge den Codierungsrichtlinien, aber wenn wir etwas anfassen, das gegen die Richtlinien verstößt und wir keine Zeit haben, es neu zu formatieren, folgen wir dem Stil, der in diesem Code vorherrscht.
Aus meiner Erfahrung hilft allein das Bewusstsein für diese Ebenen erheblich dabei, konsistenteren und damit durchaus besseren Code zu schreiben.
Wenn Sie mehr über Codierungsstandards erfahren möchten, schauen Sie sich andere CSS-Tricks-Beiträge zu diesem Thema an, und wenn Sie eine kurze, sehr kurze Lektüre dazu wünschen, vielleicht auch Das kleine Buch der HTML/CSS-Codierungsrichtlinien.
Ich möchte dem widersprechen, wenn ich kann. Ich nehme an, es ist diskutabel, aber es scheint der erste Schritt zu sein, die Standards zu vergessen/zu ignorieren.
Meine Gedanken sind genau dieselben. Es bringt die Angelegenheit zurück zur individuellen Konsistenz, nur eben nicht zu Ihrer eigenen. Aber ich bin eher nonkonformistisch; ich benutze Tabs, weil 1 Tab effizienter ist als 4 Leerzeichen. Egal ob beim Hinzufügen, Löschen oder anderweitigen Behandeln.
Ja. Ja. Ja.
Das ist alles, was ich zu diesem Thema zu sagen habe.
:-)
In meiner Firma werden die meisten UI-Projekte von einem bestimmten Entwickler „besessen“, und wir haben festgestellt, dass Stufe 2 für uns sehr gut funktioniert. Wir kommen aus verschiedenen Hintergründen und haben sehr unterschiedliche Codierungsstile – nicht nur in Bezug auf die Formatierung, sondern auch in Bezug auf Muster und Bibliotheken. Nachdem wir uns lange mit der Einigung auf einen einzigen Stil schwergetan hatten, haben wir beschlossen, dass der „Besitzer“ eines bestimmten Projekts diese Entscheidungen für dieses Projekt trifft, was uns allen komfortabel und konsistent gehalten und uns gegenseitig nicht in die Quere gekommen hat. Allerdings sind wir hier nur zu dritt, und ich bezweifle, dass diese Praxis weit skalieren würde.
Ich hatte gehofft, Sie hätten einige Daten zur Untermauerung dieser Ideologien... diese Ideen sind in der gesamten Ingenieurwelt verbreitet und sie ergeben Sinn, aber hat jemand jemals eine Studie durchgeführt, um die Hypothese zu verteidigen, dass Konsistenz Qualität hervorbringt?
Wir verlieren tatsächlich ziemlich viel Zeit mit der Einhaltung von Styleguides oder der obsessiven Formatierung von Code und entwickeln möglicherweise Feindseligkeit, wenn wir die Autorschaft einer Codezeile eines anderen einfach ändern, um seinen Stil zu korrigieren – überwiegen die Vorteile der Konsistenz diese Nachteile?
Verwenden Sie Linter oder Tools wie Stylelint/Stylefmt, um einen Code-Stil zu erzwingen? In modernen Entwicklungsumgebungen wird die Codeformatierung größtenteils von Lintern und Build-Tools übernommen.
@Jz, verstehe ich Sie richtig, dass Sie sich fragen, ob Entropie/Unordnung tatsächlich ein Problem wäre?
Ich gebe zu, es gibt einen Reiz darin, und wir sollten das wahrscheinlich untersuchen, und doch führt mangelnde Konsistenz (und damit mangelnde Konsistenz) aus Erfahrung zu viel Produktivitätsverlust, da wir jedes Mal, wenn wir den Code anderer Leute betrachten, Zeit verlieren, uns zu orientieren und den jeweiligen Code zu verstehen. Dieser Verlust mag gering sein, wenn wir erfahren oder einfach nur Glück haben, aber wir haben wahrscheinlich auch schon eine Menge Zeit im Code eines anderen *nur wegen der unterschiedlichen Formatierung* verbracht. Und das ist die empirische Seite, die darauf hindeutet, dass Ordnung, Konsistenz und Richtlinien nützlich sind.
(Ich würde sofort „Qualität“ über konsistenten Code schreiben, aber ich sehe, dass das eine etwas andere Debatte ist.)
CODE DER FUNKTIONIERT ist der einzige „beste“ Code xD
Daumen hoch!
Hilfreich könnten .editorconfig-Dateien sein
http://editorconfig.org/