Tabs vs Spaces: Auf dem Weg zu einem besseren Fahrradschuppen

Ich muss gestehen, dass ich lange Zeit nicht mehr mit dem Kampf zwischen Tabs und Spaces konfrontiert war, weil meine Teamkollegen und ich während der meisten Programmierkarriere die Standardeinstellungen beibehalten haben, sodass wir alle damit verbundenen Probleme auf magische Weise vermieden haben. Glücklicherweise hatte auch keiner von uns eine starke Meinung dazu. Das erste Mal, dass ich sah, dass es ein Problem sein könnte, war, als ich anfing, als Softwareingenieur bei der Windows Core OS Division von Microsoft zu arbeiten, wo Entwickler Leerzeichen über Tabulatoren im Windows-Quellcode verwenden mussten.

Das Windows-Team selbst hatte damals über 4000 Ingenieure. Es ist schwierig, alles in einer solchen Größenordnung konsistent zu halten, daher habe ich genau verstanden, warum einige Regeln erforderlich sind. Es gab keine Rechtfertigung für Leerzeichen in der Dokumentation, aber das selbst ist eine Botschaft: Konsistenz ist viel wichtiger als die tatsächliche Wahl.

Die Debatte über Tabulatoren im Vergleich zu Leerzeichen ist nicht das größte Problem im Produktivitätsbereich, aber wenn die Leute darüber streiten, verwenden sie Argumente, die zumeist irrelevant sind. Der erste und wichtigste Punkt ist die persönliche Präferenz, auch bekannt als "Mit Registerkarten kann ich den Quellcode so sehen, wie ich es mag".

Aber Sie sehen, Ihr Geschmack spielt keine Rolle. Niemand kümmert sich darum, was Sie für Ihre persönlichen Projekte verwenden, an denen nur Sie arbeiten. Verwenden Sie Emoji-Variablennamen, vertikale Tabulatoren, schreiben Sie in Arabisch, oder, wenn Sie noch verrückter werden möchten, verwenden Sie PHP, was auch immer Sie in die nächste Zeile bringt, zu Ihrem nächsten Projekt. Sie können die Quelle auch dann sehen, wenn Sie Leerzeichen verwenden.

Die Präferenz von Tabulatoren gegenüber Leerzeichen spielt nur eine Rolle, wenn Ihr Projekt kollaborativ ist. Es ist nur wichtig für Teams. Ihre persönlichen Vorlieben bedeuten in diesem Zusammenhang nichts. Wenn es also eine Präferenz gibt, die besser ist als die andere, muss dies diejenige sein, die eine einfachere Konsistenz bietet.

Sie sollten den Quellcode niemals so sehen, wie Sie möchten. Sie sollten es so sehen, wie es dem Team gefällt. Eigentlich tust du das. Vergiss die Tabs. Was sehen Sie sonst noch an einem Quellcode, wenn Sie ihn anzeigen? Nichts. Ihre IDE kann die Namenskonventionen von Variablen nicht auf magische Weise nach Ihren Wünschen umwandeln, sie kann keine geschweiften Klammern setzen, ohne den Code zu verfälschen, oder sie kann nicht die erforderlichen Refaktoren anwenden, damit Sie anfangen, ihn zu mögen. Nein. Es gibt keine Möglichkeit, die Quelle in einem Team so anzuzeigen, wie Sie es möchten. Sie sehen es immer so, wie das Team es sieht. Und das ist auch gut so. Da das Team das gleiche Verständnis davon hat, wie es aussehen sollte, sind Codeüberprüfungen einfacher durchzuführen. Sie müssen nicht die Vorlieben Ihres Kollegen für das Anzeigen der Quelle ärgern, wenn Sie Pairing-Programme ausführen, da Sie den Code wie das Team sehen.

Linus Torvalds forderte 8-stellige Tabulatoren und eine Zeilenlängenbeschränkung von 80 Zeichen für den Linux-Kernel-Quellcode, nicht weil er ein Sadist ist, sondern weil es die Mitwirkenden veranlasst, tief verschachtelten Code nicht zu schreiben. Ein Code, der vertikal fließt und weniger verschachtelt ist, ist viel einfacher zu lesen als dieser:

Suuuuure-du-kannst!

Trotz der Verwendung von Tabulatoren hat Linus alle dazu gezwungen, eine feste Einzugsbreite zu verwenden. Er ignorierte persönliche Vorlieben, da die feste Breite einen wichtigen Zweck hatte: die Codequalität hoch zu halten. Er hätte genauso gut 8-stellige Einrückungen mit Leerzeichen vorschreiben können, was das Umgehen erschwert hätte. Warum hat er stattdessen Tabs ausgewählt?

Die Verwendung von Tabulatoren für Linux-Code hat unter historischen Gesichtspunkten möglicherweise Sinn gemacht. Linux Source war eines der größten Open Source-Projekte, das aus Millionen von Codezeilen bestand. In früheren Zeiten von 66-MHz-CPUs mit 4 MB Arbeitsspeicher und EIDE-Festplatten hätten Tabs schnellere Build-Zeiten und effizienteren Speicher bieten können.

Oder Linus hat einfach die Standardeinstellungen übernommen, dh 8 Zeichen breite Tabulatoren zum Einrücken, und die Argumente dafür später nachgerüstet. Denn selbst wenn wir im heutigen Linux-Kernel-Code von maximal 3 Einrückungen pro Codezeile ausgehen, würde die Verwendung von Tabulatoren insgesamt eine Einsparung von 100 MB bedeuten. Das heißt, Sie wissen nicht, wie viel dieser Browser-Tab im Arbeitsspeicher Ihres Computers belegt. Tabulatorzeichen bieten Ihnen also auch bei den größten Projekten keinen wirklichen technischen Vorteil mehr.

Sie verlieren Metadaten mit Registerkarten

Das Verwenden von Tabulatoren ist verlustbehaftet. Hierdurch werden die Informationen zur Teampräferenz für die Einzugsbreite gelöscht. Das Team kann ihre Präferenz für Codierungsstile nicht korrekt an andere weitergeben, wenn sie sich an Tabulatoren halten. Durch die Verwendung von Registerkarten erschwert das Team den Beitragenden die Anpassung. Dies ist eine verpasste Gelegenheit, sich weiterzubilden. Räume hingegen sind in diesem Sinne selbstdokumentierend.

Tabulatorzeichen sind auch nicht selbstverständlich. Sie sind nicht von Leerzeichen zu unterscheiden, es sei denn, ein Werkzeug unterstützt sie speziell. GitHub nicht. Wenn Sie den Code für ein Projekt auf GitHub anzeigen, wissen Sie nicht, ob der Typ Tabulatoren oder Leerzeichen bevorzugt und wie viele Zeichen breit sind, wenn Sie ihn sich nur ansehen. Ihre Pull-Anfrage für dieses Projekt kann stattdessen Leerzeichen enthalten, es sei denn, das Projekt verfügt über ein Beitragsleitliniendokument und Sie haben es gelesen.

Das Schlimmste, was Sie mit Tabulatoren und Leerzeichen machen können, ist, sie zu verwechseln. Diese Unfälle können auch schwer zu bemerken sein. Verwirrende Tabulatoren für Leerzeichen sind nur möglich, wenn Sie das verdammte Zeichen tatsächlich in die Quelle einfügen können. Zugegeben, Tools können diese Probleme beseitigen. Wenn Sie sich jedoch an die Verwendung von Leerzeichen für Einzüge halten, ist es unmöglich, dieses Problem an erster Stelle zu verursachen. Umgekehrt ist es nicht möglich: Sie können nicht einfach überall Tabulatoren für Leerzeichen verwenden. Verwechslungen sind unvermeidlich.

Die "No Rule" -Regel

Es kann sein, dass Leerzeichen nicht immer für Einzüge verwendet werden können, z. B. in der Sprache Go, in der Tabulatoren häufig verwendet werden und die immer beliebter wird. Es ist nicht sinnvoll, hiervon abzuweichen, da das mitgelieferte Tool fest verdrahtet ist, um Tabulatorzeichen zu verwenden. Foltern Sie sich nicht unnötig. Halten Sie sich an die Vorlieben Ihres Teams. es ist am wichtigsten. Halten Sie sich an etablierte Muster. Aber wenn Sie die Wahl haben, verwenden Sie Leerzeichen. Es wird dir das Leben leichter machen.

Ich habe noch nicht einmal die Oberfläche der Argumente für beide Seiten zerkratzt und glaube mir, es gibt zu viele von ihnen, aber ich denke, diese sind diejenigen, die heute noch gültig sind oder am sinnvollsten sind.

Wenn sich das neue Teamprojekt, das Sie erstellen, auf einer Plattform befindet, die eine einfache Einstellung zum Einfügen von Registerkarten als Leerzeichen zulässt, sollten Sie es in Betracht ziehen. Denken Sie an die Hölle, die Sie vermeiden würden. Es gibt kleine, fröhliche Schönheiten von Räumen.

P.S. Nein, Sie müssen nicht mehrmals die Leertaste drücken, um Leerzeichen einzuziehen.