Note: Content might be outdated!
Hantierst du öfter mal mit mit dem Code oder Markup anderer Leute? Dann kennst du vielleicht dieses warme Gefühl, das sich von der Magengegend aus im ganzen Körper ausbreitet, wenn du merkst: Wow, da hat jemand, den ich gar nicht kenne, an mich gedacht! Oder nicht.
Symptom
Ego-Code ist mein Begriff für das Gegenteil. Markup zum Beispiel, dem du gleich ansiehst: Da hat sich jemand – mit welcher Begründung auch immer – einen feuchten Lutscher um Konventionen, Lesbarkeit oder wartungsfreundlichen Code geschert.
- Ockhams Rasiermesser? Nie gehört.
- BEM, OOCSS, SMACSS, oder irgendeine logische, wartbare semantische Konvention in Markup und Stylesheet? Nicht doch.
- CSS-Preprozessoren wie SASS? Weiche, Satanas!
Während man den Einsatz von Preprozessoren und strengen Syntaxkonventionen bei kleineren Web-Projekten ja noch durchaus berechtigt in Frage stellen könnte, gehören Maßgaben wie das Sparsamkeitsprinzip (dem erwähnten Herrn Ockham sein Gesichtsdegen) neben einem kompletten Set von Standards unzweifelhaft ins Handgepäck aller Webentwickelnden.
Beispiel: CSS-Standardstile
Bis auf ganz wenige Ausnahmen sollte jedes Hauptstylesheet für ein Projekt mit einem Reset oder Normalizing beginnen. Letzteres beinhaltet, auf ersteres folgen die Standardstile für semantische HTML-Elemente.
/* Block-Elemente */
p {}
ul, ol {}
ul li {}
ol li {}
blockquote {}
/* etc. */
/* Inline-Elemente */
a {}
a:visited {}
a:hover {}
strong {}
em {}
code {}
mark {}
del {}
cite {}
/* etc. */
Ein recht komplette Übersicht der fraglichen Elemente findet sich beispielsweise bei WP Test. Mir persönlich gefällt u.a. der Styleguide von Craig Dennis besonders gut.
(Update: Link entfernt, die Seite wurde leider offline genommen)
In den Standardstilen werden solche Dinge geregelt wie die Formatierung von Listen, Links, Zitaten und dergleichen. Warum ist das wichtig und darf nicht fehlen?
Konsequenzen
Egal, ob ich einen Quelltext selbst verfasst habe, oder die Vorgaben von jemand anderem nutze:
Wenn ich ein HTML-Dokument oder eine WordPress-Seite redaktionell bearbeite, möchte ich mich nicht um Stile scheren müssen, sondern mich auf meinen Inhalt konzentrieren und den möglichst fokussiert ins Reine schreiben.
Bei jeder Textvorschau über fehlende oder kaputte Formatierungen zu stolpern, fördert nicht gerade die Konzentration. Andersherum kann ein Schriftbild, dass bereits in der Vorschau stimmt und meine Inhalte schön darstellt, durchaus stimulierend wirken (vgl. Jason Santa Maria, How we read).
Fazit
Ich bin überzeugt: Ego-Coding spiegelt eine innere Haltung wider; ein Mindset, in dem die Zukunft des eigenen Outputs im Hinblick auf Bearbeitung oder Wartung praktisch gar nicht vorkommt.
Natürlich möchte ich Ego-Codierenden nicht generell bewusste Ignoranz unterstellen. Sicher meinen es einige sogar besonders gut und wollen ihren Job einfach schnell, effizient und pünktlich erledigen.
Auch bin ich mir durchaus im Klaren, dass das Leben kein Ponyhof, Konsistenz eine Illusion und das Gerede von Standards im Angesicht realer Projektsituationen mitunter wohlfeil ist.
Wenn die Vorgaben eines Kunden oder Arbeitgebers mit ins Spiel kommen, kann Ego-Coding unter Umständen systemimmanent werden. Nicht selten scheinen Budget und/oder Zeitrahmen einen wohl durchdachten Aufbau des Projekts einfach gar nicht erst zuzulassen; zügig vorzeigbare Ergebnisse sind alles, was zählt.
Therapie
Den ultimativen Pfad der Weisheit für Ego-Codierende kenne ich nicht, aber ich habe eine Spur. Sie führt, über Vorposten wie eine lernbereite Grundhaltung und ständiges Lernen, in Richtung eines Kategorischen Imperativs und letztlich ganz simpler Empathie. Auch die – wenigstens theoretische – Auseinandersetzung mit Ideen wie Slow Coding wird auf die Dauer niemandem schaden.
Bei zeitlich straffen Projektanforderungen kann hingegen ganz einfach eine gut gepflegte Toolbox konkrete Wunder wirken. Einsatzbereite Komponenten für gängige Code-Szenarien, wie zum Beispiel ein gut dokumentiertes Starter-Theme- oder eine Plugin-Boilerplate , ermöglichen ein standarisiertes Arbeiten auch unter den real-wahnsinnigen Rahmenbedingungen des normalen Freelancer-Alltags.
Wenn du glaubst, du könntest eventuell vom Symptom des Ego-Codierens befallen sein, mach’ dir einfach klar:
Kein Mensch ist eine Insel. Was du in deinem Leben Markup tust und was du unterlässt, hat Konsequenzen für deine Mitmenschen Kolleginnen und Kollegen.
Standards sind nicht umsonst Standards geworden; wenn du sie gedankenlos ignorierst, ohne dafür einen triftigen Grund zu haben, werden du oder deine Nachfolger wahrscheinlich daran zu knabbern haben.
Umgekehrt kannst du dich, wenn du Standards und Best Practices beachtest, in der Gewissheit sonnen, dass in naher oder ferner Zukunft jemand deinen Code vor der Nase haben und dankbar deiner gedenken wird – mit diesem warmen Gefühl, das sich von der Magengegend aus im ganzen Körper ausbreitet: Wow, da hat jemand an mich gedacht …
Schön, wenn diese/r Jemand du selbst gewesen bist! 😉
Howdy Caspar!
Ein schweres Thema. Ich glaube wir müssen hier auch stark an unserer eigenen Toleranz arbeiten. Jeder hat andere Ideale. Allerdings gibt es auch – leider unsichtbare / nicht definierte – Grenzen in der Web-Dev-Welt. Das Wort „Best Practice“[1] trifft es hier wohl ganz gut (erklär das mal nen Kunden!).
Es scheint mir schon fast, als wäre es heutzutage unmöglich „unsauberen“ Code zu schreiben. Mich würde es auch sehr interessieren: Wieso ist das so? Fehlt die Zeit[2]? Lust? Vorgaben? Mittel? Kompetenz? Disziplin? Drang nach Ordnung?
Selbst wenn es an den persönlichen „Eigenschaften“ fehlt, im Vergleich zu früher (nein früher war nicht alles besser! :-)), können heutzutage IDEs wahre Wunder bewirken und jedem[3] sehr behilflich sein.
Angefangen von der Code-Analyse (Metriken, Code Smells, Datenflussanomalieanalyse, ..), über (Live-)Code-Refactoring bis hin zu voll automatisierten Testumgebung.
Ich würde gerne einen kleinen Buch-Tipp da lassen: „Clean Code: A Handbook of Agile Software Craftsmanship“ von Robert C. Martin. Ein Muss für jeden Programmierer – aber man kann immer Parallelen zu anderen Bereichen ziehen. 🙂
Grüßli und schönes Rest-Wochenende,
Chris
[1] Wer definiert, dass eine „Best Practice“ wirklich die beste Practice ist? In unserer Welt ist meist der „Hype“-Faktor ausschlaggebend. Leider.
[2] Faule Ausrede!
[3] Ich habe nichts gegen VIM-/Notepad/WebIDE-User, auch diese können sauberen und guten Code schreiben! Hier sind allerdings starke persönliche Faktoren (Disziplin, Kompetenz, Drang nach Ordnung, …) erforderlich. Bitte nicht mit dem „IDE vs. Text-Editor“ anfangangen..
@Chris Vielen Dank für deine Einschätzung und den Buchtipp! (Der Kommentar war, aus mir noch unerfindlichen Gründen, zunächst im Spam gelandet.)
hi Caspar
wieso ist jemand ein Egoist, wenn er oder sie nicht SASS nutzt?
ist die Nutzung von SASS Standard, sollte sie es deiner Meinung nach werden, so als Voraussetzung CSS zu beherrschen und zu können?
Hi Monika, diese Lesart (vor allem eine Pauschalisierung zu „Egoist“) entspricht nicht meiner Intention, aber ich nehme sie gerne zum Anlass für ein Präzisierung:
Der Standard für CSS heisst unstrittig CSS, und nicht SASS oder LESS. Wie oben angemerkt, denke ich, die Projektbedingungen sollten dafür entscheidend sein, ob und welche Hilfsmittel zum Einsatz kommen.
Bei kleineren Projekten kann man sich SASS/LESS und dergleichen bestimmt ohne Weiteres sparen. Bei Projekten wie Plattformen oder größeren Shops hingegen sollte man m.E. schon spezielle Gründe haben, um auf Präprozessoren oder einen Task-Manager (Grunt, Gulp) zu verzichten – schon alleine, weil sie u.a. einen fließenden Übergang zwischen Prototyping und finaler Umsetzung ermöglichen.
Grundsätzlich bringen die genannten Tools natürlich überhaupt nichts, wenn damit semantisch sinnfreier, suboptimal strukturierter oder überladener Code erzeugt wird. Oder anders gesagt: Ob mit dem Hammer oder mit der Nagelpistole – wenn man ein Bild aufhängt, sollte man optimal einen und maximal zwei Nägel in die Wand kloppen, nicht mehr.
ich glaub ich beginne zu verstehen. 🙂
Für mich gehört es zum Projektmanagement die Tools festzulegen, wenn in einem Team gearbeitet wird //werden muss.
Wenn jemand allerdings nach mir ein an einem Kunden ausgeliefertes WP-Theme bearbeiten mag//muss, wird er nicht umhin kommen die Doku zu lesen, weil ich schon aus Gründen der Kompatibilität mit Newsletter, Pagespeed etc völlig anders liefere als ich damit arbeite.
Minibeispiel: HTML-Kommentare sind für einige E-Mail Clients Spamgrund. Und wer das CSS in above the fold und anders trennt, hat 100% keine hoch dokumentierte Version mehr online 🙂
Unabhängig, dass ich damit gelebt habe, dass fast jede Agentur ihre CSS-Standard Vorschriften hat, die manchmal sogar jedwede performte CSS Schreiberei verhindert.
Übrigens genauso wie die Vorschriften für Themes im wp.org Repositorium, wenngleich ich diese Standards absolut verstehe und sogar befürworte.
Das Problem ist doch viel eher, dass es keine offiziellen Standards gibt. Außer natürlich W3C. Dort wirst du aber vergeblich nach Reset.css, Boilerplate oder CSS-Präprozessoren suchen. Caspar, wo sind also diese „Standards“ definiert, von denen du schreibst?
Nur weil Craig Dennis eine Zeilenhöhe von 1.414 zum Optimum erklärt, auf Grund des Tritonus-Verhältnis – was aus dem musikalischen Bereich stammt und dort als instabiles Intervall angesehen wird, im mathematischen Bereich aber eine komplexe Berechnungsstruktur aufweist – nur deshalb werde ich es sicher nicht als das Maß aller Zeilenhöhen ansehen und die Typographie somit auch nicht daran ausrichten. Um nur mal ein Beispiel aufzugreifen.
SMACSS ist zwar auf github, hat einige Aufmerksamkeit erlangt, aber noch nicht einmal den Weg ins Wikipedia geschafft (bislang). Es flammten und werden immer wieder Diskussionen aufflammen, die Standards etablieren wollen – ich erinnere mich noch sehr gut an den Versuch der einheitlichen Benennung von Containern. Aber wirklich als „Standard“ durchgesetzt hat sich davon nichts. Ich hoffe, ich konnte deutlich machen, worauf ich hinaus will.
Sobald eine Standardisierung in den Bereich wahrnehmbarer Output/vereinheitlichter Style (s. Zeilenhöhe) greift, wird die Gefahr eines Website-Einheitsbrei groß. Man siehe nur was Bootstrap 2 da angerichtet hatte. Ich zumindest kann auf den ersten Blick eine Bootstrap 2-Website erkennen, Bootstrap 3 ist hier deutlich besser geworden.
Mein Fazit: Standard ist, bzw. wäre gut, in den Bereichen der Termini, Code-Struktur, aber nicht in der Ausgabe. Nur existiert der leider offiziell nicht 🙂
Hi Angelika, auch dein Kommentar war, komischer Weise, zunächst im Spam gelandet, sorry.
Nach „offiziellen“ Standards zu schauen, halte ich für eine Falle. Die kann und sollte es für unseren Kontext hier nicht geben, das wäre Diktatur. 😉 Ob eine Zeilenhöhe im Tritonus-Verhältnis, oder im Verhältnis des Goldenen Schnitts, oder in sonst einem Verhältnis zur Schriftgröße und Spaltenbreite steht, dürfte weniger wichtig sein, als die Tatsache, dass wenn sie es tut, jemand sich augenscheinlich Gedanken gemacht (oder wenigstens mit glücklicher Hand kopiert) hat.
Ich denke, dass gesunder Menschenverstand uns sehr weit bringen kann. Solange mir klar ist, was ich tue und warum, heben Beliebigkeit und Nachlässigkeit keine Chance. Darum ging’s mir hier.
Schwierig. Wie Chris so schön schrieb: „[1] Wer definiert, dass eine “Best Practice” wirklich die beste Practice ist? In unserer Welt ist meist der “Hype”-Faktor ausschlaggebend. Leider.“
So wie ich es verstanden hatte, geht es um lesbaren Code. Ich kann für mich persönlich die optimalste best practice Lösung entwickelt haben: Meine eigene (faule) termini, um CSS-Klassen in SASS zu benennen (und nicht der vorgestellten Strukutr von SMACSS folgen) und heraus käme dennoch sauberer Code. Für den nächsten, der in den Code hinein schaut, würde dies (ohne offizielle Standards) aber erst einmal eins bedeuten „Einarbeitungszeit“. Dafür gibt es ja auch Dokus, wie Monika bereits erwähnte.
Sicher, aber diese Einarbeitung kann kurz und leicht, oder lang und mühselig ausfallen, je nachdem, wie konsistent ein/e Vorgänger/in mit seinen/ihren eigenen best practices umgeht. Und dann gibt es da noch die größeren Projekte (Magazine, Online-Ausgaben größerer Zeitungen, Shops und andere Plattformen), bei denen ich mir wirklich gut überlegen sollte, vielleicht doch lieber auf einen der bekannteren Standards zurück zu greifen, die sich in ähnlichen Szenarien bewährt haben. Es sei denn, ich habe eine eigene Namenskonvention entwickelt, die ins Große und Unwägbare skaliert in punkto Semantik und Erweiterbarkeit immer noch halbwegs Sinn ergibt.
Wer eine saubere Dokumentation hinterlässt, fällt aus dem oben erörterten Theorem eigentlich schon mal per se raus, oder? 😉 Mit einer vernünftigen Doku beweise ich ja schon, dass ich verantwortlich der Nachwelt gegenüber denke und handle.
Es gibt auch „dieses warme Gefühl, das sich von der Magengegend aus im ganzen Körper ausbreitet, wenn du merkst: Wow, da hat jemand,“ ausschließlich uglifizierte, präprozessorisierte und ungemappte Dateien ausgeliefert und ich muss das jetzt debuggen… 😉
@Heiko Genau! 🙂 Es geht hier primär wirklich nicht um Präprozessor oder nicht, sondern um wartbaren Code.
wartbarer Code 🙂
wenn ich nun ganz streng bin, so quasi als iTüpfelreiterin durch die Welt gehe, was ich nicht ohne den Schalk im Auge kann:
CSS ist eine Auszeichnungssprache und sicher keine Programmiersprache.
Daher meine Frage: was meinst du mit „wartbaren Code“?
Mir kommt die Bezeichnung Code in Verbindung mit einem CSS Beispiel neben dem Wort debuggen und mappen irgendwie sehr irritierend vor.
All die besten Praxis beschreibenden Artikel, die ich in den letzten Jahren fand, widersprachen sich zum Teil und wurden von Agenturen geschrieben, die genau ihre Art und ihr Tool das sie verwenden als die beste Praxis in die Welt jagten.
ohne Kommentarbenachrichtigung via E-Mail verlier ich hier immer den Faden merk ich grad.
@Monika Ok, die Beispiele oben kommen alle aus dem Frontend-Bereich, aber die prinzipiellen Aussagen, um die es mir hier geht, würde ich für PHP-Entwickler/innen als genauso relevant betrachten: lesbare Formatierung, das Einhalten von Coding Standards (welche auch immer, aber eben möglichst konsistent) und gute inline Dokumentation.
(Für E-Mail-Benachrichtigungen teste ich gerade eine Alternative zu Jetpack. Mehr Sorgen macht mir gerade meine AntiSpam-Bee-Konfiguration; dieser Kommentar war schon wieder im Spam gelandet.)
Es kommt leider so häufig vor, gerade bei Agenturen, dass es wichtiger ist, schnell etwas sichtbares zu erzeugen. Viel zu schnell hat man dann mit falschen Entscheidungen angefangen und kann nicht mehr zurück. Zeit, die man in nachhaltige Entwicklung, QA, Sicherheit, etc. steckt, wird nicht gewürdigt, sondern dann (Ironie des Schicksals!) als schlechte Arbeit interpretiert, weil mehr Zeit für wenig(er) Sichtbares gebraucht wird. Erweiterbarer Code, sicherer Code, wartbarer Code, etc. ist irrelevant – es muss schnell, schnell gehen. Der Fisch stinkt meistens vom Kopf her …
@Torsten Interessant, kann ich aus meiner eigenen (allerdings recht beschränkten) Agentur-Erfahrung so nicht bestätigen. Bei meinem derzeitigen Arbeitgeber wird ziemlich gründlich auf die Einhaltung sowohl der WordPress Coding Standards, als auch selbst auferlegter Maßgaben geachtet. Wenn das bei anderen Agenturen nicht so ist – weiß jemand, warum nicht?
Bei meinen Erfahrungen handelt es sich um Werbe-, Design- oder Online-Marketing-Agenturen, also Agenturen, die nicht direkt mit Entwicklung zu tun haben. Daher ist das wahrscheinlich schlicht und einfach ein Wissenslücke. Sie kennen „mobile first“ und „responsive“ nur als Werbeausdrücke, verstehen aber den Großteil dahinter nicht.