PHP Blogger

Startseite Schreib mir ne Mail! RSS Abo Webnews

Über Leerzeichen, Tabs und Absätze

Die Artikelserie über Code-Konventionen bzw. den Code-Styleguide geht weiter. Nach dem Artikel über richtiges Kommentieren und die Benennung von Variablenbezeichnern werfe ich heute mal einen Blick auf Einzüge (Spaces vs. Tabs), Leerzeichen und Absatzarten.

Was gibts für Themen?

  1. Die Wahl des Einzuges (Tabs vs. Spaces)
  2. Leerzeichen zwischen Funktionsbezeichnern und Parameterklammern
  3. Absätze - Windows oder Unix?

Und los gehts:

Die Wahl des Einzuges - Tabs vs. Spaces

Seit Entwicklergenerationen ein Diskussionspunkt: Leerzeichen oder Tabs? Schauen wir uns mal unvoreingenommen die Vor- und Nachteile der beiden Möglichkeiten zum Einrücken an:

Leerzeichen werden auf jedem System gleich dargestellt (wenn eine Mono-Space-Font zur Anzeige verwendet wird, bei der alle Buchstaben die gleiche Breite besitzen). 2 Leerzeichen sind also immer 2 Leerzeichen, nicht mehr und nicht weniger. Nachteil: Bei hohen Bildschirmauflösungen verlieren ein paar Leerzeichen schnell am Einrückungscharakter.

Tabs ist ein (alter) Standard für Einrückungen. Wieviele Leerzeichen einem Tab entsprechen, ist meist dynamisch einstellbar - meist ist ein Tab stellvertretend für 4 Leerzeichen. Je nach Bildschirmauflösung kann man gegensteuern und einen Tab breiter oder schmaler gestalten. Praktisch auch beim Ausdruck - wer einen guten Editor hat, kann für den Ausdruck eine andere Einrückung definieren, als auf dem Bildschirm (und so Platz sparen). Nachteil: Eigentlich gibt es keinen.

Da die Editoren standardmäßig alle nicht druckbaren Zeichen ausblenden und es Texte furchtbar unübersichtlich macht, wenn man sie einblendet (also ich werde da total kirre), kann man rein optisch kaum zwischen Tabs und Spaces unterscheiden.

Und da geht auch schon das Dilemma los: In vielen Projekten werden Tabs und Spaces vermischt. Warum? Teilweise unterschiedliche IDEs und Editoren, vor allem bei Open Source Projekten passiert das häufig. Auch wer ein Freund von Copy & Paste ist und sich schnell mal eine Funktion aus dem Internet kopiert, hat schnell eine Vermischung drin.

Ich bevorzuge Tabs, die sind flexibler - für was man sich aber entscheidet, ist Geschmackssache. Im Endeffekt muss man nur bei einer Sache bleiben. Mein Tipp: IDE und Editor Einstellungen einmal definieren und für alle anderen Team-Mitglieder exportieren.

Leerzeichen zwischen Funktionsbezeichnern und Parameterklammern

Ich bin schon häufig drüber gestolpert und finde es wirklich grässlich: Leerzeichen um Bezeichner und Paramter von einander zu trennen… Das Gleiche gilt für Kontrollkonstrukte wie If, Switch oder Schleifen:

Demnach gibt es zwei Varianten:

function meineFunktion (Param1, Param2){
}

vs.

function meineFunktion(Param1, Param2)
{
}

genau wie:

if (false === true) vs. if(false === true)

Das gleiche gilt natürlich auch bei Funktionsaufrufen. Ich bevorzuge keine Leerzeichen als Trenner - der Grund ist ganz einfach: Man kann die Parameter der Funktion zuordnen. Wem das als Grund nicht reicht, der kann Spaces als Trenner verwenden ;)

Auch hier gilt wie immer: Wie ist egal, hauptsache einheitlich!

Absätze - Windows oder Unix?

\n vs. \r\n - schon wieder ein leidiges Thema. Ich denke man sollte hier international denken, wie man es auch bei seinen Bezeichnern macht:

  • \r\n: “deutsche” Absätze, wenn das Projekt nicht veröffentlicht wird (= kein Open Source)
  • \n: “englische” Absätze, wenn das Projekt internation als Open Source verwendet wird.

Wer seine Projekte immer mit den selben Absatztypen ausstatten möchte, sollte sicherlich \n bevorzugen. Auch hier der Tipp: IDE und Editor-Einstellungen exportieren und allen Team-Mitgliedern zur Verfügung stellen.

Absätze vor der öffnenden Block-Klammer?

Nun möchte ich noch einen anderen Schandfleck des Programmierstils beleuchten: Keine Ahnung, wer es war, aber dieser jemand hat sich ausgedacht, das es schön wäre, wenn man den Absatz vor der öffnenden { Klammer weglässt. In etwa so:

function meineFunktion(Param1, Param2) {
    if(false !== true) {
        // Bla Bla
    }
}

Puh, hat das einen Vorteil? Ausser das man eine Zeile spart? Ich finde es wesentlich praktischer, wenn man die Blockklammern auf gleicher Höhe platziert. So hat man immer den Überblick, wenn man kontrollieren muss, ob jede öffnende Klammer ein Gegenstück hat. Und umgekehrt.

Es lebe:

function meineFunktion(Param1, Param2)
{
    if(false !== true)
    {
        // Bla Bla
    }
}

Ähnliche Artikel:

  1. PEAR ist kein Framework
  2. Benennungs-Konventionen
  3. Javascript und CSS komprimieren

.mario meint dazu:

30. November 2007 um 13:40

Immer sinnvoller als selber gestrickte Guidelines:

http://pear.php.net/manual/de/standards.php

Und um nicht alles per Hand zu checken:

http://pear.php.net/package/PHP_CodeSniffer

Nervt bei größeren Projekten - beim PHPIDS hat die komplette Validierung ca. drei bis vier Stunden gedauert ;)

Grüße,
.mario

timi meint dazu:

30. November 2007 um 15:27

Hey Mario,

dank Dir für den Hinweis… Wie gut eine Guideline ist, ist letzten Endes Geschmacksache. Für große Bibliotheken wie Pear natürlich überlebenswichtig!

Wer sich die Arbeit sparen möchte, selbst eine Codingguideline auszuarbeiten, sollte auf jeden Fall auf einen Quasi-Standard wie Pear zurückgreifen (macht eine eventuelle Eingliederung auch einfacher ;).

Wer Projekte auf Framework-Basis entwickelt, sollte sich auf jeden Fall an die Framework Guidelines halten. Siehe:

http://manual.cakephp.org/appendix/conventions
http://framework.zend.com/manual/de/coding-standard.html

.mario meint dazu:

3. Dezember 2007 um 14:18

Agree - wobei die Framework-Conventions ja eher als Benennungs-Konventionen zu sehen sind, die PEAR Guideline aber eher in die direkte Formatierung eingreift.

Die ZFW Konvention ist ja schon sehr nah an PEAR - nur eben ein bisschen weniger hart.

timi meint dazu:

3. Dezember 2007 um 14:27

Ja, das stimmt natürlich… Wobei man Pear fast auch schon als Framework sehen könnte ;)

Aber das wollen die Jungs ja nicht hören *zwinker*

.mario meint dazu:

3. Dezember 2007 um 16:50

“Wobei man Pear fast auch schon als Framework sehen könnte ;)”

Autsch! ;)

RSS für Kommentare zu diesem Artikel · TrackBack URI

Schreib Deine Meinung