Tach!

(Die Pfeile sind Tabs, die Punkte sind Spaces.)

Das ist natürlich hochgradig falsch, aber es sieht korrekt aus, solange niemand was an der Einstellung ändert, dass die Tab-Weite genau 4 Leerzeichen entspricht.

Nö, hochgradig falsch kann gar nicht sein, weil Tabs und Spaces im gezeigten Beispiel verlustfrei gegeneinander austauschbar sind und auch die Einrückung nur Optik ist und syntaktisch bedeutungslos ist. Wenn überhaupt, dann ist nur die Lesbarkeit betroffen. Das erschwert vielleicht das Verstehen und die Bearbeitung, aber "falsch" geht anders.

Also, das war jetzt vielleicht nicht das beste Beispiel, sondern eins, das ich mir schnell aus meiner Twitter-History ergooglet habe. In dem Sinne sorry für die Faulheit. :) Ich weiß nicht, ob da Tabs und Spaces wirklich austauschbar wären.

Mein Punkt sollte jedenfalls sein: Sobald man eine andere Tab-Weite nutzt als der Autor des Codes, wird die Einrückung falsch, weil Tabs und Spaces zu ungünstig vermischt sind. Da geschätzte 92,7 % aller Entwickler eine Tab-Weite von 4 Spaces nutzen, ist das in der Regel zwar wenig problematisch, aber sobald irgendwer oder irgendwas dann doch mal eine Tab-Weite von 8 oder 2 oder so nutzt, wird es von der Einrückung her Kraut und Rüben. (Das kann ich prinzipiell auch durch Beispiele belegen, weil es mir wirklich ständig unterkommt.)

Wenn du allerdings argumentierst, dass die Optik (bzw. Lesbarkeit) von Code den Code nicht (optisch und im Sinne der Lesbarkeit) „falsch“ macht, dann ist das meines Erachtens eine andere Diskussion.

Deshalb entstehen dann so Sachen wie auf dem Screenshot oben. Das ist keine Boshaftigkeit, und ich würde es nicht mal als „Inkompetenz“ bezeichnen. Es passiert bloß einfach.

Das passiert nicht "bloß einfach", Wenn man mit zu einfachen Editoren statt einer Entwicklungsumgebung arbeitet oder einem auf Programmieren ausgelegten Editor, die einen darauf hinweisen, wenn man Tabs und Leerzeichen gemischt einsetzt, und außerdem die Einrückung selbständig vorschlagen. Mischmasch ist also einfach vermeidbar.

Trotzdem tritt er auf. Ich erfinde das nicht. Und ehrlich gesagt: Ich halte es für ein Märchen, dass jeder „gute Editor“ so was vermeidet. Abgesehen von dem Aspekt, dass Code meines Erachtens auch mit simplen Mitteln sinnvoll editierbar sein sollte.

Ein Argument für Spaces und gegen Tabs: Jedes Tab aus nahezu jedem Quellcode kann durch Spaces ersetzt werden, ohne dass sich an der grundsätzlichen Lesbarkeit des Codes etwas ändert. Spaces kann man hingegen nicht gänzlich entfernen, weil sie in jedem Fall innerhalb von Zeilen benötigt werden. Tabs sind aber unter fast allen Umständen völlig optional. Das Zeichen braucht in Quellcode nicht aufzutauchen. Würde man völlig auf Tabs verzichten, gäbe es die gesamte Klasse von Problemen, auf die ich auf dem Screenshot hingewiesen habe, nicht.

Das sind Gedanken, die man sich mit den passenden Werkzeugen überhaupt nicht machen muss. Code-Reformatieren unter Berücksichtigung des Kontextes ist für IDEs und Programmierer-Editoren kein Problem und nur ein Tastendruck.

Es bleibt dennoch eine Klasse von Problemen, die viele Leute und viele Workflows gewissermaßen überfordert und die ohne weiteres vermeidbar wäre.