Javascript ist, angesichts seiner etwas holprigen Entstehungsgeschichte eine eigentlich recht elegante Scriptsprache. Es krankt jedoch daran, dass in Javascript im Grunde alles geht und alles gemacht wird und jedesmal anders. Will man mit Kollegen zusammen an einem Javascriptprojekt arbeiten, ist der eigene Dialekt ebenso hinderlich, wie mangelnde Sauberkeit beim Codeschreiben. Beachtet man aber neben einem guten Stil in Javascript einige elementare Regeln, kann man seine Scripte dadurch auch noch merklich schneller und kompakter machen.

Coding Guidelines

In Sachen Coding Guidelines gilt auf jeden Fall: jede Regel ist besser als keine Regel. In Javascript kann man viele böse Dinge schreiben, die kein Mensch versteht, die aber trotzdem hervorragend funktionieren. Die Sprache lässt einfach vieles zu, was trotzdem schlechter Stil ist. Vor kurzem haben sich die Entwickler von jQuery einen Styleguide verpasst, die JQuery Core Style Guidelines, das ist schon eine wunderbare Grundlage. Einfach copy & pasten.

Wichtig ist dabei auch, die Verwendung von JS Lint (JSLint will hurt your feelings.). Mit diesem Tool kann man die übelsten Stylefehler vermeiden und die Einhaltung des Styleguides automatisiert überprüfen. Die Einführung dazu ist mehr als lesenswert. Besonders praktisch für Nutzer von Textmate (Lieblingseditor) ist das JS Lint Bundle.

Codeverbesserung: erster Durchgang

Sich aufzuraffen, seinen Code zu überarbeiten, ist nicht leicht. Aber: der Wille zur Verbesserung und das Wissen, dass der erste Aufschlag meist nicht optimal ist, trennt den Programmieren vom Scriptingguy, oder so. Hier ein paar schnelle und einfache Schritte, die Javascript schon deutlich verbessern. Federice Galassi hat darüber eine wunderbare Präsentation gemacht. Die Maßnahmen führen aber nicht nur in Richtung unobtrusiveness, sondern sind auch geeignet, Javascript schneller und wartbarer zu machen. Kurz zusammengefasst:

1. Entferne alles Inline-Javascript aus dem HTML-Code.

   Also <script> Code…</script> raus aus den Seiten und in eigene Dateien (besser eine eintige) packen. Diese dann mit <script src="datei.js"></script> aufrufen. Und das am besten am Ende der Seite, direkt vor </body>.

2. Alle Inlineevents aus dem HTML entfernen

   Weg mit <a class="klick" href="#" onclick="foo();">Klicken Sie hier</a>. Das kann besser machen. Mit jQuery beispielsweise: $("a.klick" ).bind("click", function() { foo(); });, jedenfalls aber in der externen Javascriptdatei.

3. Javascript-Pseudolinks entfernen

   Mit Todesstrafe wird der uralte Javascript-Pseudolink bestraft! Sowas geht gar nicht: <a href="javascript:foo()">Klicken Sie hier</a>

4. CSS-Code aus dem Javascript entfernen.

   Innerhalb des Javascriptes sollte kein CSS verwendet werden (Trennung von Präsentation und Programmierlogik). D.h. sowohl Zuweisungen wie $("a" ).css("background","#ff0000" ); oder auch document.getElementById("id").style.color("#ff0000"); und ähnliches schreiben teilweise lange unüberschaubare style-Attribute in den HTML-Code und produzieren DOM-Zugriffe. Stattdessen schreibt man die CSS-Anweisungen in eine CSS-Datei

   // bspw. base.css
   a.rot {
   	background: #ff0000;
   }
   

   und nutzt im Javascript

   $("a").addClass("rot"); // Farbe an
   $("a").removeClass("rot"); // Farbe aus, oder gleich:
   $("a").toggleClass("rot"); // je nach dem
   

   CSS bewegt sich wesentlich schneller und gewandter durch das DOM als Javascript.

5. Businesslogik aus dem Javascript entfernen (Client-Server-Anwendungen).

   Bei Client-Server-Anwendungen kann es einen entscheidenen Geschwindigkeitsvorteil bedeuten, komplizierte Berechnungen nicht auf dem Client (also mit Javascript) sondern auf dem Server auszuführen. Wenn man sich also schon Daten vom Server holt, dann sollte man vermeiden mit diesen Daten Berechnungen auf dem Client auszuführen. Ein Beispiel:

   // Schlecht!
   $.get("action.php", function ( data ) {
       if ( data ) {
           if ( data.kontostand > data.dispokredit ) {
               alert("Konto überzogen" );
           }
       }
   });
   
   // Besser!
   $.get("action.php?dispoberechnung", {konto:"123456"}, function ( data ) {
       if ( data.dispo === false ) {
           alert("Konto überzogen" );
       }
   }
   

6. DOM-Operationen auf ein Minimum beschränken!

   Nicolas Zakas formuliert es in High Performance JavaScript (Build Faster Web Application Interfaces) so:

   An excellent analogy is to think of DOM as a piece of land and JavaScript (meaning ECMAScript) as another piece of land, both connected with a toll bridge (see John Hrvatin, Microsoft, MIX09, http://videos.visitmix.com/MIX09/T53F ). Every time your ECMAScript needs access to the DOM, you have to cross this bridge and pay the performance toll fee. The more you work with the DOM, the more you pay. So the general recommendation is to cross that bridge as few times as possible and strive to stay in ECMAScript land.

   Daraus ergibt sich eine klare Anweisung: greife sowenig wie es eben geht auf das DOM zu.

   Ein Domzugriff ist dann gegeben, wenn ein DOM-Element erschafft, ins DOM einhängt, ein Element im DOM verschiebt, Attribute hinzufügt und so weiter und so fort. Am allerschlimmsten sind die sogenannte HTML-Coolections und das iterieren hierauf.

   // ein ganz böses Beispiel!
   function innerHTMLLoop () {
       for ( var i = 0; i < 15000; i++ ) {
           document.getElementById("meinLink" ).innerHTML +="a";
       }
   }
   

   Hier erleben wir schlappen 15000 DOM-Aufrufe der übelsten Art. Stattdessen vermeidet man solange wie möglich den Zugriff aufs DOM:

   // dann besser so
   function innerHTMLLoop2 () {
       var content ="";
       for ( var i = 0; i < 15000; i++ ) {
           content +="a";
       }
       document.getElementById("meinLink" ).innerHTML += content;
   }
   

   Goldene Regel: pro Funktion sollte es nur einen Zugriff auf den DOM geben. So kann es beispielsweise Sinn machen, sehr lange auf Strings mit HTML zu arbeiten und erst am Ende alles zusammen per $( var ).appendTo( 'body' ); ins DOM zu hängen. Ausser in Chrome und Safari ist es sogar noch schneller innerHTML zu benutzen, in jQuery $("#meinKram" ).html( var );. Hier scheiden sich allerdings die Geister, weil innerHTML nicht standardkonform ist, wohl aber von jedem Browser unterstützt wird.

7. Große HTML-Chunks ggf. durch Templates ersetzen.

   Wegen der schon oft angesprochenen Trennung von Content und Präsentationslogik ist zu überlegen, ob man für große HTML-Stücke die man in den Code einspeisen muss, vielleicht besser HTML-Templates verwendet, den Code also in externe Dateien auslagert und nachlädt (auf welche Weise auch immer). Als Vorstufe dazu und Kompromiss kann man auch bis mittelgroße Codeschnipsel im verborgenen Teilen des HTML-Dokuments unterbringen und sich dann per .clone() oder wieder .html() einlesen und wiederverwenden.

   Die Verwendung eines Templatesystems setzt aber bspw. wieder ein eingenes Plugin voraus, Schnipsel im HTML verursachen beim Laden wieder DOM-Zugriffe. Hier muss man genau abwiegen, was der Performance hier zuträglich ist, sicherlich auch in Abhängigkeit vom der Größe des HTML-Codes der benötigt wird.

8. Keine/wenig globalen Variablen nutzen!

   Variablen die ausserhalb von Funktionen definiert werden, sind, auch wenn sie mit var geschrieben werden, globale Variablen, die im window-Namensraum gespeichert werden. Es besteht die Gefahr, dass diese an anderer Stelle ungewollt überschrieben werden, außerdem ist der Zugriff auf window langsam. Stattdessen speichert man Variablen aus dem Window-Namensraum in lokalen Variablen zwischen, auf die der Zugriff wesentlich schneller erfolgt.

Fortsetzung folgt

Dieser 8-Punkte-Plan ist aber nur ein Einstieg. Wenn man ein Programm so optimiert hat, kann man praktisch direkt wieder von vorne anfangen und weitere Verbesserungen einbringen. Das wird dann das Thema eines weiteren Artikels hier.

Bei der Verleihung des Biene Awards letzte Woche in Berlin¹ wurde ich gefragt, ob das jetzige ZEIT ONLINE quasi zufällig so gut geworden wäre. Zunächst empfand ich die Frage als dämlich, mithin frech. Beim genauerer Überlegung muss ich jedoch zugeben: preiswürdige Barrierefreiheit ist tatsächlich bei der Entwicklung mehr als Zugabe herausgefallen, als dass wir darauf zugesteuert hätten. Die Gemeinschaftsleistung aller Beteiligten, von den Information Architects in Japan und in der Schweiz, über Nexum, die Erdfische und das Digitalkombinat, hat uns in Hamburg genug Freiheit in der Codegestaltung gegeben, dass zunächst nur Validität und letzten Endes dann wohl auch Barrierefreiheit möglich wurden.

Als ich bei ZEIT Online angefangen habe, da bestand die Site noch aus einer großen, merkwürdigen Tabellenkonstruktion. Seitdem hat sich einiges geändert: zunächst stellten wir auf CSS um, damals noch mit schlimmster <div>-terie, einen Relaunch später versuchten wir wenigtens stellenweise valide zu sein, was nicht durchgängig gelang. Heute ist zumindest dieses Ziel erreicht. Meistens. Die Wahrheit ist, dass man regelmäßig Kontrollen machen muss, ob noch alles in Ordnung ist.

Aber, das wissen wir alle: das alleine macht ja keine Barrierefreiheit aus. In der Laudatio wurde es aber auch schon deutlich: das gelungene Design (Japan/Schweiz) und der Einsatz allermodernster Techniken wie HTML5 (Hamburg), sowie die gute Typographie (Japan/Schweiz/Hamburg) haben einen guten Teil des Ergebnisses ausgemacht. Wenn ich die Andeutungen richtig verstanden habe, war es auch ein wenig umstritten, ob man ZEIT ONLINE auszeichnen solle, oder das Ergebnis war zumindest knapp. Was ich gut verstehen kann, denn obwohl unser Motto lautet: »Wir sind die Guten!«, hatten wir doch schon das Gefühl, allein wegen der schieren Masse an Code nicht in alle Ecken vorgedrungen zu sein, um dort mit gutem Zureden, freundlichen Worten und zur Not eiserner Faust die Richtlinien durchzusetzen, die man braucht, um eine barrierefreie Seite zu bauen. Außerdem besteht unser Team zwar aus Jungs, die in HTML und CSS träumen und das Geträumte morgens durch den W3C-Validator jagen, aber anderseits sind wir nicht mit der BITV oder den WCAG, jedenfalls nicht täglich.

Das wir dafür die Biene in Bronze erhalten haben, die aussagt, dass da noch Raum für Verbesserungen ist, noch Luft nach oben, zeigt uns, dass man trotzdem bereit war unsere bisherige Arbeit positiv zu bewerten. Das ist natürlich ein großer Ansporn, um auf dem Weg weiter zu gehen. Und sicherlich auch eine Legitimation mehr, denn letzten Endes muss man sich auch immer für längere Entwicklungszeiten, kompliziertere Konstrukte und das teilweise sture Beharren auf bestimmte Codestrukturen verantworten. Da ist der Preis sicherlich Wind von hinten.

Last but not least möchte ich noch auf eine Sache hinweisen, auch weil es bei der Verleihung kurz zur Sprache kam: als Newswebsite müssen wir natürlich in einem teilweise sehr hartem Verdrängungswettbewerb bestehen, im Rennen um die beste Platzierung in der Google-Suche, den meisten Nennungen bei Google News und so fort. Wir haben aber im letzten Jahr kontinuierlich versucht SEO-Maßnahmen als eine Form der Zugänglichkeit zu verstehen. Scheinbar hat auch das, jedenfalls an den meisten Stellen, sehr gut funktioniert, in beide Richtungen.

¹ ZEIT ONLINE wurde eine bronzene Biene in der Kategorie »tagesaktuelle Recherche- und Serviceangebote« verliehen

Bild: http://www.flickr.com/photos/adactio/ / CC BY 2.0

Andreas Dölling ist laut Autorenangbae Webentwickler, kann es aber nicht lassen, seine Nase immer wieder in Bereiche zu stecken, die ihn eigentlich gar nichts angehen, und seine Meinung dazu kundzutun. Schon passiert würde ich mal sagen, obwohl ich dachte, dass CSS einen Webentwickler sehr wohl etwas angeht.

Zunächst einmal ist es natürlich eine super Sache, seine CSS-Klassen gut und semantisch zu benennen, es werden auch wirklich schöne und einleuchtende Besipiele genannt, die Herr Dölling einem alten Hasen abgescahut hat bzw. zu denen ihn das Qualitätsmanagement einer professionellen Firma gezwungen hat. Scheinbar aus Rachen gegen die Affront jedoch hat sich Herr Dölling noch einige Reste eigenen CSS-Stils bewahrt und die haben es in sich. Mein Vorschlag dazu: auf gar keinen Fall nachmachen!

Anordnung von CSS-Eigenschaften

Es wird empfohlen, Eigenschaften in der Reihenfolge der Wichtigkeit zu notieren, wobei in fünf Wichtigkeitsgruppen eingeteilt wird (Verhalten, Position und Dimension, Abstände und Rahme, Schriftgröße und Zeilenhöhe, Hintergrund und übrige Eigenschaften). Dämliche Idee numero uno: erstens halte ich die Wichtigeit von CSS-Eigenschaften für höchst diskutabel, das kommt halt immer auf den Fall an, in Wahrheit ist dies ein willkürliche Festlegung. Wogegen man eigentlich gar nichts einwenden kann, denn wenn es keine logische Reihenfolge gibt ist koordninierte Willkür der einzige Weg. Nur sind diese Gruppen schwer vemittelbar: man muss lernen, was zu welcher Gruppe gehört, lernen in welcher Reihenfolge die Gruppen anzuordnen sind und innerhalb der Gruppen, gibt es gar keine definierte Reihenfolge. Stellen sie sich einmal vor, sie sind Qualitätsmanager und sollen nun dieses Regelwerk an diverse Webentwickler und -dekorateure kommunizieren. Schönen Dank. Ich sag’s mal in CSS-Inquisitions-Sprache: wird sich nicht durchsetzen. Zu kompliziert, zu schwierig umzusetzen.

Der Gegenvorschlag bleibt bestehen: CSS-Eigenschaften immer in aplhabetischer Reihenfolge notieren. Das ist einfach, versteht jeder, ist eine nachprüfbare, also durchsetzbare Regel und super umsetzbar. Und führt auch auf lange Sicht zu lesbaren Stylesheets.

Einrückung und Umbrüche

Endgültig die Haare zu Berge stehen einem dann, wenn man die Idee zum quer schreiben liest. Herr Dölling, lassen sie sich an dieser Stelle einmal folgendes sagen: wer quer schreibt, ist noch lange kein Querdenker, eher schon ein Quertreiber. Mal davon abgesehen, dass die letzte Übersichtlichkeit, die Herrn Döllings drolliger Dialekt noch bietet, einzig und allein durchs Synthaxhighlighting zustande kommt, ist dies ein CSS-Code der sagt: »Fass mich nicht an! Mein Autor ist so von sich selbst überzeugt, dass er nicht glaubt, dass jemand anderes ausser er selbst Änderungen vornehmen möchte.« Danke schön.

Sowas darf man sicherlich auf den Server stellen, es spart eine Menge Platz und sicherlich das eine oder andere Byte an Gewicht. Aber während der Entwicklungszeit ist so eine Schreibweise einfach nur eins: kontraproduktiv. Man stelle sich nur vor, man soll jetzt hier eine CSS-Regel hinzufügen, womöglich nach der vorgenannten Fehllehre, sozusagen irgendwo in der 400 Zeichen langen Zeile. Wir wünschen fröhliches horizontal scrollen. Das ist wirklich eine dumme Idee. Auf gar keinen Fall nachmachen.

Hoffe, das war jetzt inquisitorisch genug, war ja auch so gewünscht. Da kann einem aber auch der Geduldsfaden reissen. Schon passiert: hier habe ich eine Videoaufnahme davon:

http://www.youtube.com/watch?v=gldlyTjXk9A

Nachtrag: ich habe heute morgen in meiner grenzenlosen Weisheit Dämlichkeit diesen Artikel aus Versehen gelöscht und musste z.T. von Hand restoren, dabei sind die Pingbacks flöten gegangen. Sorry.

»It’s not everything that bad…« ©BBC

Kommentare

Mehrzeilige Kommentare, mit Einrückung et al. sind zu platzieren:

• am Beginn jeder Datei
  • mit Angabe wozu und an welcher Stelle das Stylesheet benötigt wird, kurze Inhaltsangabe o.ä.
  • Abhängigkeiten
• vor jedem Themenabschnitt

Codebespiel: mehrzeiliger Kommentar

/**
 * Hello World
 * Dies ist ein mehrzeiliger Kommentar
 */

In allen anderen Fällen ist der Zeilenkommentar zu nutzen

Codebespiel: einzeiliger Kommentar

/* Dies ist ein einzeiliger Kommentar */

Leerzeilen

Einzelne Regeln sind durch 1 Leerzeile voneinander zu trennen. Es sollten niemal mehr als 2 Leerzeilen aufeinander folgen.

Codebespiel: Leerzeilen

.note { border: 1px solid #000; }

.black_note {
    background: #ff00ff;
    color: #000;
}

Anm.: Bitte den Code immer so leserlich wie möglich gestalten. Optimierung des CSS auf Größe wird in späteren Buildprozessen umgesetzt und ist vom Layout unabhängig.

Kurzschrift-Eigenschaften

Wo immer möglich und sinnvoll sollen die Deklarationen in Kurzschreibweise zusammengefasst werden.

Codebespiel: Kurzschreibweisen 1

.small {
    background: transparent url(img/border-bottom.gif) repeat-x bottom;
    border: 1px solid #000;
}

Trotzdem bitte flexibel bleiben und davon abweichen, wenn es sinnvoll ist:

Codebespiel: Kurzschreibweisen 2

a:link {
    background: transparent url(img/sprite.gif) no-repeat 0 0;
}

a:hover {
    background-position: 0 -16px;
}

Best practice

Bitte jede Deklaration immer mit einem Semikolon abschließen.

Namen

• alle Namen in Kleinbuchstaben
• zusammengesetzte Namen mit _ (underscore) verbinden
• eher aber kurze Namen suchen, höchstens 1 Zusammensetzung
• Update: Klassennamen verraten nicht das Aussehen eines Elementes. (via) D.h. Klassen heissen nicht “.grey-border” oder ähnliches.

Reservierte IDs: folgende IDs sind in der Regel für das HTML-Gerüst vergeben und sollen außerhalb dessen nicht benutzt werden:

• #wrapper
• #container
• #header
• #content
• #sidebar
• #footer

To be continued.

Begriffsklärung

Codebespiel: Begrifflichkeiten

h2 { color: #000; }

• Diese Codezeile ist eine CSS-Regel (rule)
• h2 ist (hier) ein Selektor (selector)
• color: #000; ist die Deklaration (declaration)
• color ist eine Eigenschaft (property)
• #000 ist ein Wert (value)

Nachzulesen beim W3C.

Schreibweisen

• Alle IDs und Klassennamen klein schreiben
• Alle Selektoren klein schreiben
• Alle Deklarationen klein schreiben
• Alle Werte klein schreiben

Codebespiel: Schreibweisen

h2, #container, .formbox { color: #efe; }

Leerzeichen (Space)

• Zwischen Deklaration und Wert (nach dem Doppelpunkt)
• nach Kommata
• bei einzeligen Selektoren nach { und vor }
• nach /* und vor */

Einrückung

• Selektor auf eigener Zeile, dahinter {-Klammer
• Deklarationen (1 pro Zeile) eingerückt um vier Leerzeichen
• }-Klammer am Ende wieder ausgerückt

Codebespiel: Einrückung 1

.note {
    border: 1px solid #000;
    color: #ff0000;
    margin-bottom: 10px;
}

Ausnahme: Selektor mit nur 1 Deklaration wird einzeilig geschrieben

Codebespiel: Einrückung 2

.note { border: 1px solid #000; }

Regeln, die sich auf Kindelemente beziehen, werden an der Mutter-Regel ausgerichtet.

Codebespiel: Einrückung 3

.note {
    border: 1px solid #000;
}
    .note p {
        padding: 4px 2px;
    }

To be continued. Update: Teil 2 ist fertig.