Einzig Wahre Einrück Tiefe
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Die EinzigWahreEinrückTiefe ist natürlich:

EinrücktiefeMotivation
1 LeerzeichenDie ET für den Individualisten, unbrauchbar aber einzigartig.
2 LeerzeichenDie minimal mögliche ET, ideal für tiefe Verschachtelungen (HTML).
3 LeerzeichenDie optisch optimale ET, außerdem: alle guten Dinge sind 3, leider absolut unbrauchbar für WardsWiki.
4 LeerzeichenDie naheliegende ET für diejenigen, denen 8 zu viel ist.
8 LeerzeichenWas könnte naheliegender sein als das TAB in Standardeinstellung?
1 TABOder gleich das TAB selber?

Leerzeichen statt TABs

Tipp: Das wichtigste bei der Einrückung ist natürlich, im Editor die Speicherung von TAB-Zeichen abzuschalten.

Die Umwandlung von TABs in Leerzeichen kostet zwar geringfügig mehr Speicher, verhindert aber die komplette Zerstörung der Einrückungsstruktur beim Wechsel und Source-Austausch zwischen Entwicklern und verschiedenen Systemen.

Hat jemand wirklich schon mal eine "komplette Zerstörung der Einrückungsstruktur beim Wechsel und Source-Austausch zwischen Entwicklern und verschiednenen Systemen" unter der Verwendung von TABs erlebt?! Ich nicht. Aber ich hätte gerne mal ein Beispiel... -- ChristianStüdemann?

Doch, ich habe das schon erlebt. Vor allem, wenn Leute stark einrücken und wenn Editoren nicht konsequent Mischungen von TABS+Leerzeichen zu TABs optimieren. Wenn das passiert, brauchst du irgendeinen pretty-printer, sonst bist du verloren. Sehen kann man das aber immer nur in Kombination zwischen verschiedenen Editoren und verschiedener TAB-Einstellungen. -- HelmutLeitner

TABs statt Leerzeichen

Tipp: Das wichtigste bei der Einrückung ist natürlich, im Editor die Speicherung von TAB-Zeichen einzuschalten.

Verwendet man zum Einrücken pro Verschachtelung genau einen TAB (und sonst nichts) so kann man Source-Austausch zwischen Entwicklern sich dauerndes re-tabben ersparen, da die TAB-Stops meist individuell einstellbar sind. Aus dem selben Grund sollten rein optische Formatierungen wie pseudo-tabellarisch aufgelistete Deklarationen mit Leerzeichen formatiert werden [wenn schon unbedingt notwendig] um in den verschiedenen Entwicklungsumgebungen nicht zu erodieren.

Was bei der Verwendung von TABs zu beachten ist

(Siehe auch ergänzende Variante weiter unten.)

Werden TABs verwendet, dürfen und müssen sie ausschließlich für die linke Einrückung der Strukturebenen herangezogen werden. Dies wird vor allem dann problematisch, wenn Entwickler lange Parameterlisten oder Methodenaufrufe auf mehrere Zeilen aufteilen:

01 void myMethod(int    param1      ,
02               double zweiterParam,
03               bool   arg3        ) {
04   codeLine1;
05   String myString= "Ein sehr sehr " +
06     "langer String " +
07     "mit vielen Zeilen im Quelltext.";
08   .
09   .
10   .
11 }

In diesem Beispiel dürfte nur eine einzige TAB-Einrückung (hier mit 2 Zeichen TAB-Länge) verwendet werden. Diese würde im Bereich der Zeilen 04 bis 10 eingesetzt, wobei fraglich ist, ob in den Zeilen 06 und 07 eine weitere Einrücktiefe (ein weiterer TAB) oder lediglich eine Einrückung durch Leerzeichen vorliegt?!

Auf jeden Fall müßte in den Zeilen 02 und 03 die Einrückung durch Leerzeichen und nicht durch TABs erfolgen, da hier die Einrücktiefe durch die Länge des Methodennamens vorgegeben wird und keine strukturelle Einrückung vorliegt.

Das Problem ist: Die meisten IDEs können nicht zwischen struktureller und ästhetischer Einrückung unterscheiden. Gibt man ihnen "Einrückung durch TABs" vor, ersetzen sie alle linksbündigen Leerzeichen so weit wie mögliche durch TABs der vorgegebene Einrücktiefe. Spätestens nach dem Abschluß von Zeile 02 im obigen Beispiel würde man mit solchen Tools in Zeile 03 ganze 7 TABs am Zeilenanfang vorfinden, die dort gar nicht hingehören.

Noch heftiger wird das Beispiel, wenn myMethod innerhalb einer Klasse definiert ist und damit bereits strukturell um einen TAB eingerückt wäre. Spätestens dann wird es schwierig, in den Zeilen 02 und 03 eine korrekte Einrückung (nämlich 1 TAB und 14 Leerzeichen) hinzubekommen. Nahezu unmöglich wird es für die "automatischen" IDE-Werkzeuge.

Alternativ kann man bei längeren Parameterlisten direkt nach der öffnenden Klammer eine neue Zeile beginnen und dann jeden Parameter bzw -gruppe in eine eigene Zeile mit einem oder zwei TAB einrücken:

01 void myMethod(
02     int x, int y,
03     double offset,
04     bool flag)
05 {
...

Fazit

(Siehe auch Fazit nach ergänzender Variante weiter unten.)

Die strukturelle Einrückung mit TABs erscheint variabel und sinnvoll, wird jedoch nur halbherzig von den gängigen IDEs unterstützt. Welcher Weg der richtige ist, wird so lange eine hitzige Diskussion bleiben, solange die Tools keine ausreichende Unterstützung liefern. Mit der unterschiedlichen Darstellung von TAB- und Leerzeichen-Freiräumen wäre schonmal ein Anfang gemacht.

Ergänzende Variante, was bei der Verwendung von TABs zu beachten ist

Hier ein ergänzender Vorschlag zur TAB-Formatierung. Überlegen wir zuerst, wie der Code ohne Umbrechungen auszusehen hat. (Im Unterschied zum vorangegangenen Abschnitt werden hier 4 Leerzeichen pro TAB verwendet.):

01 void myMethod(int param1, double zweiterParam, bool arg3) {
02     codeLine1;
03     String myString = "Ein sehr sehr " + "langer String " + "mit vielen Zeilen im Quelltext.";
04     .
05     .
06     .
07 }

Bei dem einen oder anderen Betrachter wird dieses Beispiel vermutlich bereits "rechts aus dem Fenster herauswandern". Also: Ab und zu wird man Zeilen umbrechen wollen, beispielsweise weil wie hier Zeilen "zu lang" erscheinen (wobei diese Situation deutlich seltener eintritt, folgt man BjarneStroustrups Idee, Proportionalschrift statt Schrift fixer Breite zu verwenden: http://groups.google.com/groups?selm=350FC369.5F866A9C@world.std.com).

Das linksseitige Einrücken der umgebrochenen Zeilen nehmen wir wieder per TAB vor. Damit aber die umgebrochenen Teile von blocktiefenabhängigen Einrückungen unterscheidbar sind, geben wir genau 2 TABs für dieses Einrücken hinzu. (Man könnte auch lediglich einen TAB hinzunehmen, jedoch besteht dann leicht Verwechslungsgefahr der umgebrochenen Zeilen mit einem vermeintlich eingerückten Block.)

Das auch oben bereits eher kritisch gesehene pseudo-tabellarische Ausrichten von gleichartigen Parts aufeinanderfolgender Codezeilen (in C z. B. Deklarationen mit Typ, Variable, "=", Initialisierungsausdruck, die alle in mühsamer Fummelarbeit "schön senkrecht" untereinander ausgerichtet werden) verbannen wir gänzlich. Erstens ist es häßlich wie die Nacht (ok, Geschmackssache). Zweitens - und das ist das Totschlagargument - ist es in Hinblick auf Wartung/Versionsverwaltung von äußerstem Übel, denn es würde bedeuten, dass bei Codeanpassungen oft auch umliegende, eigentlich nicht betroffene Zeilen umformatiert werden müssten. Also: Im gesamten Quelltext tauchen nirgends zwei oder mehr aufeinanderfolgende Leerzeichen auf, es sei denn im Inneren von Stringliteralen (und vielleicht gerade noch in Kommentarblöcken, wenn man halt doch mal etwas per Tabelle erklären möchte).

Den oben vorgegebenen Umbrüchen folgend sieht unser Code nun also so aus:

01 void myMethod(int param1,
02         double zweiterParam,
03         bool arg3) {
04     codeLine1;
05     String myString = "Ein sehr sehr " +
06             "langer String " +
07             "mit vielen Zeilen im Quelltext.";
08     .
09     .
10     .
11 }

Alles Tacko. Und wie folgt sieht der Code in Proportionalschrift, TABs zu 8 Leerzeichen expandiert, ohne Umbrüche (da kaum nötig), aus.

01 void myMethod(int param1, double zweiterParam, bool arg3) {
02         codeLine1;
03         String myString = "Ein sehr sehr " + "langer String " + "mit vielen Zeilen im Quelltext.";
04         .
05         .
06         .
07 }

Gar nicht mal schlecht.

Fazit nach ergänzender Variante

Die strukturelle Einrückung mit TABs "funktioniert", sie ist plausibel und praktikabel. Sie wird von den gängigen IDEs unterstützt (Gegenbeispiele?); zwar sind TABs und Leerzeichen visuell nicht unmittelbar unterscheidbar, jedoch ist dies in der Regel kein Problem (sondern eher gewollt, denn visuelle Auffälligkeiten - hier am linken Rand -, wie klein auch immer, würden eher störend als hilfreich wirken. Dass sie natürlich dennoch optional visuell hervorhebbar sein sollten, ist auch wieder klar ...)


In my egoistical opinion, most people's C programs should be indented six feet downward and covered with dirt. [Blair P. Houghton on the subject of C program indentation]

Diskussion?

Anmerkung zu "Das Problem ist: Die meisten IDEs können nicht zwischen struktureller und ästhetischer Einrückung unterscheiden.":

Ästhetik ist leider eine Frage des persönlichen Geschmacks. Mir behagt die Art und Weise, wie vielfach überlange Parameterlisten formatiert werden, überhaupt nicht. Kann mal jemand Überzeugungsarbeit leisten?

Weitere Beobachtung: Die Sprache prägt den Stil. In comp.lang.ruby wurde kürzlich humoristisch die These vertreten, man benötige mehr Klammern, damit noch mehr Leute von anderen Programmiersprachen auf SpracheRuby umsteigen ;-) In SpracheSmalltalk gibt es unterschiedliche Ansichten darüber, wie Blöcke eingerückt werden sollten (besonders knifflig beim Behandeln von Ausnahmen).

SaschaDördelmann


siehe EinzigWahreArtGeschweifteKlammernZuSetzen
KategorieProgrammierStil KategorieDiskussion
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 27. Januar 2006 13:02 (diff))
Suchbegriff: gesucht wird
im Titel
im Text