Auch zur Statik:

Ein grundsätzliches Problem bei der Verwendung von Tabs sind gleichmäßige Zeilenlängen. Es ist nicht wirklich praktikabel, entwicklerübergreifend eine Zeilenlänge von vielleicht 80 bis maximal 120 Zeichen zu gewährleisten, wenn Entwickler A mit einer Tab-Weite von 2 arbeitet und Entwickler B mit einer Tab-Weite von 8.

Wenn wir in einer Einrücktiefe von Ebene 4 sind (Klasse, Methode, zwei Kontrollstrukturen), ist „Tab=2“-Entwickler bei Offset 8 und „Tab=8“-Entwickler schon bei Offset 32. Das ist ein Unterschied von 24 Zeichen. Wenn beide Entwickler halbwegs darauf achten, keine zu langen Zeilen zu produzieren, sondern irgendwann mal umzubrechen, entsteht am Ende kein einheitlicher Code, weil der „Tab=8“-Entwickler viel eher umbricht als der „Tab=2“-Entwickler.

Um so was zu vereinheitlichen, müsste man schon eine Vorgabe machen im Sinne von: „Die Tab-Weite in unserem Projekt ist genau 4 Spaces.“ Mit anderen Worten: Man will eigentlich Spaces und kann auch gleich Spaces nehmen.

Denn auch mit einer solchen Festlegung ist das Problem mit unterschiedlichen Tab-Weiten noch nicht gelöst, denn diverse Tools (VCS, E-Mail, Projektmanagement, Print, cat, grep, diff, …), die mit dem Code arbeiten, wissen nicht, dass die Tab-Weite 4 Spaces ist. Die gehen tendenziell wahrscheinlich eher von 8 aus.

Anderer Aspekt:

Wieso ist es gerade so wichtig, die Darstellung der Einrücktiefe dem einzelnen Entwickler zu überlassen, wenn es bei jedem anderen zeichenbasierten Aspekt des Quellcodes keinerlei Variabilität gibt? Es gibt kein Zeichen, das sagt „wahlweise geschweifte Klammer mit in die Zeile der Kontrollstruktur oder in die Zeile darunter“. Es gibt kein Zeichen, das sagt „optionaler Leerraum um Gleichheitszeichen“. Es gibt nicht mal ein Zeichen, das sagt „OS-spezifischer Zeilenumbruch (schöne Grüße an Windows)“.