coding guidelines

[Tropi]

Der Haken bei der Diskussion um Space und Tabs ist ja der: Auch die Anhänger der Leerzeichen-Variante benutzen Tabs. Nur lassen sie das dann eben den Editor auf Spaces umwandeln. Mir kann niemand erzählen, das jemand bei einem Code wie dem hier:

class Test {
    public function bla() {
        if (true) {
             echo "foo";
        }
    }
} 

insgesamt 36x auf die Leertaste schlägt (nur fürs Einrücken). Genauso ist es auch beim Löschen/Ausrücken von Code. Wenn die IDE bzw. der Editor das Einrückungsmanagement nicht großteils automatisch machen würde, würden alle nur noch Tabs verwenden. Der einzige Grund der mir gegen Tabs einfällt sind diese 80 Zeichen Begrenzungen, da sich 80 Tabs nunmal nicht gut ausgehen auf einem TTY.

[rkr]

Im Zeitalter von 16:10 Screens wirken 80-Zeichen-Limits ein wenig antiquiert

[erc]

Der einzige Grund der mir gegen Tabs einfällt sind diese 80 Zeichen Begrenzungen, da sich 80 Tabs nunmal nicht gut ausgehen auf einem TTY.

Ist jetzt aber auch nicht so als hätten die IDEs dafür keine Hilfe dabei. Entweder kannst du dir eine Linie einbleden lassen (ist meisten per Default drin) oder hast ein "Lineal" am oberen Rand.

[mermshaus]

@rkr:

Leerzeichen sind wohl ursprünglich auch mal nicht dazu da gewesen, um irgendwas einzurücken? Kann man da nicht sagen, dass eine Einrückung mit Leerzeichen im traditionellen Sinne einer Zweckentfremdung gleichkommt?

Ich weiß nicht. Beim Leerzeichen ist es eben nicht so, dass der eigentliche Einsatzzweck „unmöglich“ gemacht wird, sondern dass nur eine Funktion hinzukommt. Ein Leerzeichen ist für sich erst mal auch sehr generisch. Es ist eben nur ein „leeres Zeichen“.

Wenn man Tab aber als Indent-Zeichen mit – was ja ganz zentral wichtig zu sein scheint – beliebig definierbarer Schrittweite nutzt, dann ist es nicht mehr möglich, mit den TABULAtoren Daten tabellenartig anzuordnen, weil die Tabellen nur bei einer bestimmten Schrittweite funktionieren.

Der Witz an der Stelle – das passt auch ganz gut zu Tropis letztem Beitrag – ist, dass das Auffüllen von Tabs durch Spaces im Grunde genau diesen Einsatzzweck wiederherstellt, indem die Ambiguität, wie ein Tab zu interpretieren und darzustellen ist, rausgenommen wird.

Am Rande, auch als „Gegenbeispiel“ zu Tropis „ihr drückt alle Tab“:

  * @exception   CloneNotSupportedException     if the object's class does not
  *                                             support the <code>Cloneable</code>
  *                                             interface. Subclasses that override
  *                                             the <code>clone</code> method can also
  *                                             throw this exception to indicate that an
  *                                             instance cannot be cloned.
  *
  * @exception   OutOfMemoryError               if there is not enough memory.
  * @see         java.lang.Cloneable 
  */
 protected native Object clone() throws CloneNotSupportedException;

Das ist eine Tabelle. Die kriegt ihr nicht zusammengetabbt, da drückt ihr endlos Leerzeichen, während Spaces-Leute tatsächlich tabben können. (Auch wenn das nur eine Softwaresache ist.) Das ist irgendwie ironisch, wenn man mal drüber nachdenkt.

Ihr nutzt TAB gewissermaßen rein als IND („Indenter“/„Indentator“).

Anderes Beispiel:

        $imageBackgroundColor = 'rgb(' . implode(', ', array(($backgroundColor & 0xFF0000) >> 16,
                                                             ($backgroundColor & 0x00FF00) >> 8,
                                                             ($backgroundColor & 0x0000FF))) . ')';

Viel Spaß auch hier bei der Formatierung.

Die Diskussion wäre meines Erachtens übrigens anders, wenn ein Konsens darüber bestünde, dass ein Tab immer meinetwegen mod8 ist (so definiert das etwa Linus (?) gleich im ersten Satz des Kernel Coding Styles[1]). Das würde einige Probleme mit Tabs zur Einrückung lösen. Nur würden bei mod8-Tabs vermutlich die meisten (?) Tab-Fans keine Tabs mehr nutzen wollen, weil sie mod4 vorziehen. (Das ist sicher auch noch eine Randpointe: Killerfeature von Tabs: Indentation ist frei wählbar. ~90 % der Leute wählen sowieso 4 und ändern das nie. – Ist jetzt aber natürlich Spekulation.)

1: Wenn man es festlegt, sollte man es wohl tatsächlich auf 8 festlegen.

Wenn ich bei der Einrückung Tabs und Spaces vermische, dann ist es logisch, dass das bei anderen Schrittweiten-Einstellungen zu Problemen führt. Das gilt auch, wenn ich Spaces mit Tabs vermische. Merkst du was?

Das schreibe ich aber glaube ich selbst nicht anders. Mein Argument, das nicht das stärkste ist, zugegeben, ist an der Stelle: Es besteht – im Gegensatz zu Spaces – keinerlei Notwendigkeit, überhaupt Tabs in Quellcode zu setzen. Alle Fehlformatierungen, die sich aus einem Mischmasch ergeben können und die man nicht sehen kann, wenn man die Schrittweite nicht verstellt oder sich nicht nicht-druckbare Zeichen anzeigen lässt, sind vermeidbar.

Ich frage mich dabei halt immer (und das ernsthaft nicht bloß rhetorisch), ob es wirklich so wichtig sein kann, die „Länge“ der Einrückungen optisch individuell definieren zu können, dass man sich dafür all die möglichen Probleme aufhalsen will (auch mit externen Tools, die Code darstellen oder Spalten angeben oder so). Selbst wenn du/ihr das Argument aus dem letzten Absatz nicht anerkennt, opfert man damit zum Beispiel die Fähigkeit, auf eine bestimmte Zeilenlänge schreiben zu können, denn das unterscheidet sich etwa zwischen Tab=2 und Tab=8, also potenziell zwischen zwei Leuten, die am gleichen Code arbeiten, schon recht massiv. Und auch bei einer fließenden Zeilenlänge, wird man irgendwann mal umbrechen müssen – etwa in längeren Kommentarabsätzen.

Ich verstehe nicht, wieso euch gerade die Konfigurierbarkeit an der Stelle so wichtig ist. Ihr könnt auch sonst nichts an der Darstellung verstellen (Plenken der Klammern oder so). Nur bei Tabs geht das halt „zufällig“.

Nein, kann man nicht. Nicht alle IDEs können Textblöcke mit Leerzeichen einrücken. (Ausser, man macht es manuell)

Na ja, du schreibst selbst im Effekt, dass weder Tabs noch Spaces überall funktionieren.

Das ist das einzige Argument, dass ich gelten lassen würde. "Wir müssen uns nun mal auf etwas einigen" macht das eine oder das andere aber nicht besser oder korrekter.

Meinetwegen können wir Kategorien wie „Korrektheit“ gerne weglassen. Ich bilde mir ein, das „pragmatisch“ zu sehen, aber wenn es eine einfache oder korrekte Antwort gäbe, wäre das ja nichts, über das man so schön streiten könnte.

Ich würde auch Tabs nutzen, wenn das in einem verbreiteten Standard stünde. Die Eleganz, ein Zeichen zu haben statt einer Latte von Leerzeichen, erschließt sich mir grundsätzlich durchaus. Das ändert aber nichts daran, dass ich Leerzeichen für praktischer halte.

Mit Leerzeichen kann ich zum Beispiel auch einfach nach \t suchen, um zu gucken, ob die Datei richtig formatiert ist. Wenn keins existiert, passt es. Umgekehrt geht das nicht, weil zu Zeilenbeginn vor dem Content auch ein Tab und dann vier – falsche – Leerzeichen stehen könnten. Die findet man nicht, weil man nicht trivial in einem Regex oder so zwischen falschen und richtigen unterscheiden kann.

Ich könnte deshalb mit Tabs glaube ich nur wirklich bequem arbeiten, wenn ich nicht-druckbare Zeichen auf nicht störende Weise anzeigen lassen könnte. Sonst würde ich spätestens beim Copy-&-Pasten von Fremd-Snippets einen Rappel kriegen.