Warum nicht beide?
Erstens sind "beschreibend" und "ausführlich" nicht dasselbe. Wenn Sie beispielsweise eine ziemlich lokale Schleife schreiben, iist dies ein sehr guter Variablenname für die Schleifenvariable. current_iteration_indexObwohl es wohl beschreibender und definitiv ausführlicher ist, ist es viel schlimmer und fügt überhaupt keine Informationen hinzu, da die Verwendung ials Schleifenvariable allgemein akzeptiert wird und es keine andere Bedeutung gibt i.
Gute Variablennamen sind insofern beschreibend, als ein Programmierer, der mit der Sprache und den Konventionen der Codebasis vertraut ist, leicht erraten kann, welche Rolle sie spielen, aber sie sind auch kurz genug, um die Dinge kompakt zu halten.
Die Beschränkung auf 80 Zeichen, die ursprünglich eine Folge der technischen Einschränkungen der Textterminals der 1970er Jahre war, wird von vielen heute noch geschätzt, und obwohl es immer noch technische Gründe gibt (maximale Leitungslängen in einigen Netzwerkprotokollen, insbesondere im Zusammenhang mit E-Mails). Die zwingenderen Gründe sind psychologische und soziale. Es stellt sich heraus, dass Zeilenlängen um die 66-Zeichen-Marke das angenehmste Leseerlebnis für Prosa in natürlicher Sprache darstellen (die Schriftgröße spielt interessanterweise keine große Rolle, und folglich auch nicht die Bildschirm- oder Papiergröße). Die Zeilenbeschränkungen von 80 Zeichen liegen ziemlich nahe daran, aber da der Großteil eines typischen Codeteils normalerweise mindestens ein oder zwei Einrückungen aufweist (was je nach Einrückungseinstellungen zwischen 4 und 16 Zeichen bedeutet),
Ein weiterer Effekt des Festhaltens an Zeilen mit 80 Zeichen ist, dass dies ein ziemlich guter Indikator dafür ist, wann die Dinge zu kompliziert sind. Zeilen, die lang sind, werden normalerweise durch eine der folgenden Ursachen verursacht:
- Funktionen mit einer langen Liste von Argumenten; Dies ist keine gute Sache, da sie die Lesbarkeit beeinträchtigen und leicht subtile Fehler verursachen können, z.
- Komplexe Ausdrücke, die häufig in Bedingungen vorkommen (z. B.
if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); Auch dies ist normalerweise schwer zu entziffern, und der Code sollte in etwas strukturierteres umgeschrieben werden. Höchstwahrscheinlich macht der Ausdruck zu viel und sollte in eine Methode oder Funktion herausgerechnet werden.
- Lange Literale, die in Funktionsaufrufen oder Ausdrücken verwendet werden, z
print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));. Bewegen Sie das Literal in eine Variable oder Konstante. Möglicherweise überschreitet es immer noch die Zeilenlänge. Wenn Sie dies jedoch konsequent tun, kann der Leser den unsichtbaren Teil der Zeile zumindest ignorieren, vorausgesetzt, dass nur der Rest des Buchstabens folgt. Oder noch besser, verschieben Sie die Literale aus dem Code in einen externen Datenspeicher (Datei, Datenbank, was auch immer).
- Tief verschachtelte Anweisungen, z. B. sechs Ebenen von
ifAnweisungen in einer Klassenmethode (das sind 32 Einrückspalten für typische Einstellungen). Auch hier sorgt Deep Nesting für komplexen und schwer lesbaren Code und sollte wie die Pest vermieden werden. Einfach ausgedrückt, Deep Nesting überflutet den Stapel des menschlichen Gehirns beim Lesen.
All dies sind letztendlich Symptome von Dingen, die Sie auf lange Sicht nicht in Ihrer Codebasis haben würden, und die Durchsetzung von Beschränkungen von 80 Zeichen ist eine nette und einfache Möglichkeit, die Komplexität niedrig und die Lesbarkeit hoch zu halten. (Das heißt nicht, dass Sie nicht perfekt unlesbaren Code in 80 Spalten schreiben können: Die verschiedenen Wettbewerbe mit verschleiertem Code sind ein klares Gegenbeispiel.)