< Zwölf mal zwölf - und nun? | Fritz Rau: »50 Jahre Backstage« >

04 Jan 2010 Code-Konventionen

Der geschätze Kollege Alp Uçkan hat nicht nur ein sehr interessantes (X)HTML-/CSS-Framework namens fapulous veröffentlich, sondern dieses auch – schon relativ kurz nach Veröffentlichung – bereits recht gut dokumentiert. Unter anderem beschreibt Alp die Code-Konventionen, nach denen er arbeitet, und bezeichnete diese via twitter sehr schön und zutreffend als „Handschriften“ der Frontend-Entwicklung und -Gestaltung.

Meine „Handschrift“ ist interessanterweise einerseits der von Alp recht ähnlich, in anderen Punkten jedoch auch wieder sehr unterschiedlich – sie ist dem einen oder anderen eventuell in meinen Templates und Ports bereits aufgefallen. Machen wir mal einen „Schriftvergleich“.

Einrückungen

Tabulatoren sind Teufelszeug, welches nur Probleme macht. Meines Erachtens zeichnet sich ein vernünftiger™ Texteditor schon dadurch aus, dass er Tabulatoren in Leerzeichen umwandeln kann. Allerdings benutze ich zum Einrücken normalerweise 4 Leerzeichen – das finde ich persönlich einfach übersichtlicher. Zudem entspricht es der Code-Konvention für s9y.

CSS-Klassen und -ID-Namen

Da sind Alp und ich komplett konträr – wann immer ich kann, vermeide ich CamelCaps. Auch das ist rein subjektiv, ich finde sie einfach schlechter zu lesen. Ich verwendet stattdessen komplette Kleinschreibung mit Bindestrichen als Worttrenner (.eine-klasse und #eine-id), da ich Unterstriche ebenfalls als „unschön“ empfinde, aber rein „aus dem Bauch heraus“. Zumal ich auch Tags grundsätzlich klein schreibe.

Single Lines, Leerzeichen und Interpunktion

Bei Leerzeichen und Interpunktion sind wir uns wieder einig – man kann und sollte nach Fertigstellung eines (größeren) Projektes Stylesheets minifizieren, ehe man das Projekt live stellt, aber so lange man aktiv am Code arbeitet, ist Übersichtlichkeit oberstes Gebot.

Einzeiler im CSS verwende ich allerdings nur, wenn zu einem Selektor auch nur eine Anweisung gehört: h3 { margin-bottom: 1em; }. Sobald eine zweite dazu kommt, erhält jede Anweisung eine eigene Zeile, auch das aus Gründen der Übersichtlichkeit und Lesbarkeit.

Sonstiges

Bei den margins muss ich im Vergleich zu Alp ganz ehrlich sagen: Darüber habe ich so noch nie nachgedacht, es macht aber durchaus Sinn.

Die Kommentare bei schließenden Elementen (genauer: schließenden divs) mache ich übrigens genauso, allerdings ergänze ich noch einen Klassen-/ID-Indikator (was Alp sich dank der CamelCaps sparen kann), z.B. <!-- /#eine-id -->. Das ist einfach sehr, sehr hilfreich, um bei Verwendung mehrerer divs sofort zu sehen, welches </div> zu welchem <div> gehört. (Es versteht sich von selbst, dass „div-Suppe“ generell vermieden werden sollte.)

Was ich noch mache

Ich rücke z.B. Absätze grundsätzlich so ein:

<p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
   sed diam nonumy eirmod tempor invidunt ut labore et dolore
   magna aliquyam erat, sed diam voluptua.</p>

Also so, dass der reine Inhalt eine Absatzes am Text, nicht am Tag ausgerichtet ist. Auch hier ist die einfache Begründung: „Sieht schöner aus“ – ich mag einfach optisch schönen Code.

Bei Listen breche ich übrigens ebenfalls aus ästhetischen Gründen mit der 4-Zeichen-Einrückung. Die sehen bei mir normalerweise so aus:

<ul>
   <li>list item #1</li>
   <li>list item #2</li>
</ul>

Und Ihr so?

Ich würde mich freuen, von weiteren Kollegen zu lesen, wie ihre „Handschrift“ aussieht – ich für meinen Teil finde so etwas zum einen interessant, zum anderen findet man vielleicht doch nochmal das eine oder andere, worüber man selbst so noch nie nachgedacht hat. Der Reiz an der Browserflüsterei ist ja schließlich unter anderem der, dass man immer wieder dazulernen kann und muss.

0 Trackbacks

Trackback-URL

  1. Keine Trackbacks

5 Kommentare

RSS Feed (Kommentare) für diesen Eintrag

  1. * Markus Schlegel (04.01.10, 12:47):

    Leerzeichen statt Tabs scheint tatsächlich immer populärer zu werden. Warum? Tabulator = Teufelszeug ist nicht so hundertprozentig überzeugend.

    Ich sehe Leerzeichen und Tab nicht als „Konkurrenten“, sondern als kleiner und großer Abstandhalter. Ebenen (d.h. z.B. verschachtelte Divs) hebe ich mit dem größeren Spacer hervor und zwar pro Ebene genau ein Tab. Ich könnte jetzt noch etwas von verdeckter Semantik und so erzählen, aber der eigentliche Vorteil ist dabei, dass man in den allermeisten Editoren die Tabulatorweite regeln kann, Leerzeichen sind dagegen immer gleich breit.

  2. * Michael van Laar (04.01.10, 13:20):

    Bindestriche in Klassen- und ID-Namen finde ich zwar rein subjektiv auch angenehmer zu lesen. Aber ich meine, mal irgendwo gelesen zu haben, dass es mit solchen Bindestrichen (im Gegensatz zu Unterstrichen) irgendwelche Probleme gibt, sobald JavaScript ins Spiel kommt. Ich habe das nie getestet, habe mir aber angewöhnt, Bindestriche in Klassen- und ID-Namen zu vermeiden.

  3. * YellowLed (04.01.10, 13:43):

    @Markus: Meiner (recht bescheidenen) Erfahrung nach erzeugen Tabulatoren vor allem in Projekten mit einem zentralen Code-Repository oft Probleme. Verschiedene Leute mit verschiedenen Editoren auf verschiedenen Systemen und mit verschiedenen Einstellungen fummeln an denselben Dateien rum. Zudem (aber das mag eine “Macke” meines emacs sein) irritiert es mich rein optisch, wenn Tabulatoren beim editieren des umliegenden Codes “hüpfen” :)

    @Michael: Wäre mir so noch nicht untergekommen, ich mache allerdings auch wenig Javacript und wenn, dann mit jQuery. So ist es mir bislang noch nicht aufgefallen.

  4. * Chris (04.01.10, 13:56):

    -soupe…Bon appétit.
    Immer diese Templates und Vorlagen…das ist der größte Müll.

    divdivdivdivdiv ul li /ul /div/div/div/div

  5. * YellowLed (04.01.10, 15:35):

    Es gibt solche Templates leider, ja. Es gibt genauso Templates mit sauberem Code. Wie überall halt.

Kommentar schreiben

Bitte die Hinweise beachten.

Hinweise

Textile-Formatierung erlaubt
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Gravatar, Twitter, Identica, Favatar Autoren Bilder werden unterstützt.

Pflichtfelder sind mit * markiert.

Kommentare, die mindestens einen Link enthalten, werden moderiert. Kommentare, die mindestens 3 Links enthalten, werden abgewiesen. Sorry – Spamschutz.

Bei Emoticons, die mitten in Sätzen stehen, möglichst keine Nasen einsetzen [ :), ;) usw. ], da es ansonsten im Zusammenspiel mit Textile zu Merkwürdigkeiten kommen kann.