Die unglückliche Wahl des Coding-Styles

„Welchen Programmierstil man für ein Projekt wählt ist egal. Die Hauptsache ist, dass man sich einigt.“ Dass diese Weisheit nicht immer richtig ist, zeigt ein kleines Javascript-Beispiel, über dass ich gerade gestolpert bin. Ob eine geschweifte Klammer hinter oder unter dem if steht, kann eben doch einen entscheidenden Unterschied machen.

Auch beruflich bin ich angehalten, geschweifte Klammern folgendermaßen zu schreiben:

if (condition)
{
    // some code
}

Das ist für mich ungewohnt gewesen, aber auch kein Problem. Nach einiger Zeit gewöhnt man sich daran und findet es auch bald ansprechend. Der Mensch ist eben ein Gewohnheitstier.

Viele Empfehlungen verderben den Code-Brei

Unschön werden solche Vorgaben jedoch, wenn Programmiersprache oder Framework etwas anderes empfehlen. Dies fällt mir bei Java auf: Von Anfang an gab es hier konkrete Empfehlungen, wie Code auszusehen hat. Infolgedessen geben die meisten Projekte und Code-Schnipsel im Netz ein konsistentes Bild ab. Und auch ich schreibe Java-Code seit jeher so, wie Sun es mich gelehrt hat.

Fordert nun ein Unternehmen davon abzuweichen, so ist das mindestens ärgerlich. Oft wird hier versucht, ein sprachenübergreifend einheitliches Code-Bild zu erreichen. Diese Idee mag zunächst verlockend sein, ich halte sie aber schon aus genanntem Grund für grundlegend falsch. Will man Guidelines zum Coding-Style festlegen, sollte man sich zunächst im gegebenen Ökosystem umsehen.

Fehlerverursachende Konventionen

Kritisch wird es, wenn die Sprache sich bei bestimmten Coding-Konventionen nicht mehr so verhält, wie sie soll. Python etwa ist bekannt dafür, dass die Einrückung zur Bedeutung des Codes gehört. Doch es gibt auch versteckte Beispiele.

Betrachten wir folgenden Javascript-Code. Zwei Funktionen, die vermeintlich dasselbe machen: Ein Objekt zurückgeben. Das Ergebnis überrascht dann aber doch:

function returnObjA() {
  return {
    name: 'a'
  };
}

function returnObjB()
{
  return
  {
    name: 'b'
  };
}

console.log(typeof returnObjA());  // "object"
console.log(typeof returnObjB());  // "undefined"

Schuld daran ist Javascripts gutmütiger Umgang mit Programmierern, die gern mal ein Semikolon vergessen. Javascript versucht dann das Ende eines Ausdrucks zu erraten, was bei der zweiten Funktionen zu folgender Ergänzung führt:

function returnObjB()
{
  return;     // Ausdrucksende unerwartet erraten
  {
    name: 'b'
  };          // Unreferenzierte Objekterzeugung
}

Empfehlen lassen statt Empfehlungen geben

Schlussendlich ist die Wahl des Coding-Styles nicht unbedingt nur eine Geschmacksfrage. Eine Orientierung an größeren Frameworks oder der Programmiersprache selbst verbessern das Gesamtbild des Ökosystems sowie des Projektes selbst. Zudem kann ein kurzer Blick auf Beispiele in die Spezifikation einer Sprache unangenehme Seiteneffekte verhindern.