Beschreibende Benennung vs. 80 Zeichenzeilen [geschlossen]

17

Ich höre häufig diese zwei wertvollen Programmierpraktiken: (1) Codezeilen sollten höchstens 80 Zeichen lang sein und (2) beschreibende Namen für Variablen, Methoden, Klassen usw. verwenden. Ich verstehe jedoch die Gründe für diese beiden Ratschläge scheinen sie oft Kompromisse einzugehen. Wenn ich meinen Code unter 80 Zeichen / Zeile halte, verwende ich weniger aussagekräftige Namen (insbesondere in Python, bei dem jeder Einzug aus 4 Zeichen besteht). Wenn ich jedoch aussagekräftigere Namen verwende, werden mehr als 80 Zeichen verwendet.

Meine Frage ist also, welcher dieser beiden Ratschläge wichtiger ist, wenn die Wahl getroffen werden muss. Ich frage mich, ob ich ein unabhängiger (Hobby-) Programmierer bin, aber was noch wichtiger ist, aus der Perspektive eines Software-Ingenieurs, der für ein größeres Unternehmen arbeitet.

mjgpy3
quelle
4
@ Billyoneal Mit großen Bildschirmen, 120 :)
BЈовић
4
Ich denke, ich brauche mindestens 130
9.
8
Ich bevorzuge 80, weil ich dann problemlos 2 Dateien nebeneinander auf meinem Notebook öffnen kann.
Honza Brabec
5
Zeilen, die länger als 80 Zeichen sind, können unleserlich werden. 80 ist also eine gute Grenze. Die Beschreibung muss nicht zu ausführlich sein. Und es kommt auf den Geltungsbereich an: kurze Variablennamen mit kleinem Geltungsbereich, längere Namen mit großem Geltungsbereich. Vermeiden Sie auf jeden Fall Variablen mit großem Gültigkeitsbereich. Wenn Sie gerade dabei sind, verwenden Sie eine funktionale Sprache und teilen Sie Ihren Code in kleinere Funktionen auf, wenn er zu tief eingerückt ist -> sehr kleiner Bereich == kurze Variablennamen. Funktionsnamen sind ähnlich, aber in der Regel etwas länger, da ihr Umfang größer ist.
Peer Stritzinger
4
@ ott--: Haben Sie einen Editor gesehen, der laut C ++ - Syntax tatsächlich eine lange Zeile durchbrechen und die eingezogene Fortsetzung um eine Ebene höher darstellen kann als der Anfang? Andernfalls ist ein solcher Vorschlag unbrauchbar.
Jan Hudec

Antworten:

34

Behalten Sie Ihre Gedankenstriche bei, Ihre Namen sind aussagekräftig, und haben Sie keine Angst, eine Linie zu brechen.

Behalten Sie Ihre Eindrücke bei.

Wenn ich mich in einem Kampf zwischen Gedankenstrichen und beschreibenden Namen befinde, gehe ich oft einen Schritt zurück und schaue auf meine Gedankenstriche. Wenn Sie mehr als 3 oder 4 Ebenen einrücken (2 Ebenen sind automatisch und in vielen Fällen unvermeidbar. Lesen Sie: Definition der Klassenmethode), möchten Sie möglicherweise Ihren Code umstrukturieren und die Funktionalität auf eine Funktion oder Methode abstrahieren.

Ihre Namen sind beschreibend

Sie sollten Ihre Namen immer aussagekräftig halten. Beschreibende Namen erzeugen selbstdokumentierenden Code. In einigen Fällen können Sie versuchen, die Namen zu verkürzen, aber die Lesbarkeit steht an erster Stelle.

Hab keine Angst, eine Linie zu brechen

Scheiße passiert. Wenn Sie mehr als 80 Zeichen haben und trotzdem keine Möglichkeit sehen, Leerzeichen in der Zeile zurückzugewinnen, brechen Sie sie. Die meisten Sprachen kümmern sich nicht um Zeilenumbrüche, also teilen Sie die Zeile in mehrere. Wählen Sie nicht einfach einen zufälligen Ort aus. Halten Sie die Dinge logisch gruppiert und rücken Sie eine weitere Ebene ein, wenn Sie die Linie brechen.

Craige
quelle
3
Es ist zu beachten, dass beschreibende Namen nicht mit langen Namen identisch sind. Das Vermeiden von Wiederholungen von Dingen, die aus dem Kontext leicht ersichtlich sind, und einer Handvoll sorgfältig ausgewählter Abkürzungen (nur für die sehr gebräuchlichen Begriffe) kann einen langen Weg in Richtung kurzer beschreibender Namen gehen.
Jan Hudec
18

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.)

tdammers
quelle
1
+1: Tolle Antwort, außer dass ich nicht damit einverstanden bin, dass Literale vom Code wegbewegt werden. Wenn Sie wissen, nach welchem ​​Literal Sie suchen, können Sie in Ressourcen oder Code genauso gut danach suchen. Wenn Sie jedoch mit dem Code arbeiten und das Literal ändern müssen, ist es eine ziemliche Ablenkung, danach in einer separaten Datei suchen zu müssen. Beachten Sie auch, dass alle Sprachen die Möglichkeit haben, Literale in mehrere Zeilen aufzuteilen, was ich in einem solchen Fall tun würde.
Jan Hudec
Natürlich hat der Satz, der als Beispiel eines langen Buchstabens verwendet wird, keinen Platz im Quellcode. Solche Dinge gehen in die Seitenvorlagen ein. Aber für Dinge wie Fehlermeldungen ziehe ich es vor, sie mit dem Code zu behalten, der sie ausgibt.
Jan Hudec
@ JanHudec: Sicher, das Verschieben der Literale in eine Datendatei ist nicht immer sinnvoll. Ich spreche jedoch von zu langen Literalen, und bei diesen habe ich selten eine Gelegenheit gesehen, bei der die Definition an anderer Stelle den Code verschlechtert hätte: Die Länge des Texts wirkt sich störend auf das Lesen aus, während die Bedeutung des Texts leicht sein könnte zu einer Konstante oder einem Variablennamen zusammengefasst, den Sie an anderer Stelle definieren. Fehlermeldungen sind wohl ein Urteilsspruch.
Tdammers
16

Die beschreibende Benennung ist bei weitem wichtiger. In den meisten Oberflächen können wir scrollen, um längere Zeilen zu sehen. In keinem Fall kann das System Ihnen bei der Übersetzung von Variablen und Funktionen mit schlechtem Namen helfen.

Matt S
quelle
2
Dies. Hören Sie auf, Zeilen mit X-Zeichen zu brechen, und lassen Sie die IDE das erledigen. Anderenfalls stören Sie alle anderen Benutzer (einschließlich zukünftiger Benutzer!), Deren Bildschirme / IDEs 2 * X-Zeichen mit Code verarbeiten können, der nicht mehr auf eine Seite passt.
Konerak
4
Die Frage handelte implizit von langen Namen. Und ich stimme nicht zu, dass Namen lang sein sollten - die meiste Zeit sollten sie kurz sein . Beschreibende, lange Namen können das Lesen von Code erschweren als etwas weniger beschreibende, aber kürzere Namen! (Zu lange Zeilen sind im Allgemeinen schwer zu lesen.)
Konrad Rudolph
4
Ich stimme dir nicht zu. Wenn ich den Code nicht sofort sehe, ist er schwer zu lesen, egal wie aussagekräftig die Namen sind.
Jan Hudec
4

80 Zeichen pro Zeile sind nicht schwer zu erfüllen, auch wenn die Benennung lang ist, da es viele Möglichkeiten gibt, eine einzelne Zeile langen Codes in mehrere kurze Codes zu unterteilen. Ich kann z. B. eine Bedingungsanweisung in C in mehrere Zeilen unterteilen, damit sie in weniger als 40 passt Zeichen,

if ( a == b || c == d  || d == e
    || c == e || c == a || c == k
    || c == l)

Sie können eine Funktionsaufrufzeile auch in mehrere Zeilen aufteilen.

Daher sind sowohl die Regeln für die beschreibende Benennung als auch die Regeln für 80 Zeichen widerspruchsfrei und können zur Verbesserung der Lesbarkeit nebeneinander existieren.

Neo
quelle
2
Verbessert 80 Zeichen wirklich die Lesbarkeit? Welcher Bildschirm kann heutzutage nicht mehr ohne weiteres 120?
Billy ONeal
7
@BillyONeal Es ist einfacher, über 80 Breite als über 120 Breite zu scannen
Ratschenfreak
2
Das Nachrichtenblatt ist in Spalten unterteilt, und Sie können weitere Informationen von ux.stackexchange.com/questions/3618/…
neo
1
Das Aufbrechen einer logischen Bedingung verbessert die Lesbarkeit, wenn die Zeilenumbrüche der Struktur der Bedingung entsprechen, jedoch nicht unbedingt, wenn sie nur einer beliebigen Grenze entsprechen.
mikołak
1
@BillyONeal: Die meisten Bildschirme können 120, aber kaum 240 Bildschirme. Oder vergleichen Sie niemals Unterschiede?
Hubert Kario
0

Das 80er-Limit hätte schon lange erhöht werden müssen. Beachten Sie, dass dieses Limit seit dem Alter verwendet wird, in dem die Länge jedes Bezeichners auf 8 Zeichen und nur eine Schriftart auf dem Bildschirm / Drucker beschränkt war. Keine Möglichkeit, die Schriftgröße zu ändern.

Gott, wir haben jetzt verschiedene Sieb- und Drucktechnologien. Wir haben sehr unterschiedliche Programmiersprachen. Es gibt keinen Grund mehr, 80 Zeichen zu verwenden. Erhöhen Sie es auf mindestens 120 Zeichen.

Selbst dann sollte es keine harte Grenze sein. Sie gehen ein Zeichen über die Linie? Nun, nichts passiert!

Bearbeiten:

Detaillierte Antworten zur Geschichte des 80-Zeichen-Limits

Zeichen pro Zeile auf Wikipedia

Eine Studie an der Wichita State University ergab, dass CPL nur geringe Auswirkungen auf die Lesbarkeit hatte, einschließlich der Faktoren Geschwindigkeit und Verständnis. Bei der Frage nach Präferenzen gaben jedoch 60% der Befragten an, entweder die kürzesten (35 CPL) oder die längsten (95 CPL) Zeilen zu bevorzugen, die in der Studie verwendet wurden. Gleichzeitig wählten 100% der Befragten eine dieser Größen als am wenigsten wünschenswert aus.

Sulthan
quelle
4
Nein, das Limit sollte definitiv nicht erhöht werden. Da es absolut nichts mit Sieb- und Drucktechnologie zu tun hat, kann nur mit der Tatsache, dass 80 Zeichen pro Zeile ungefähr das Maximum des menschlichen Auges darstellen, komfortabel gescannt werden (66 Zeichen gelten als optimale Zeilenbreite, weniger beim mehrspaltigen Druck). Dies bedeutet übrigens, dass die meisten Bücher weniger als 80 Spalten für Codebeispiele enthalten.
Jan Hudec
3
@JanHudec Es hat alles mit der Sieb- / Drucktechnik zu tun. Siehe programmers.stackexchange.com/questions/148677/… . Die Entscheidung für 80 Charaktere ist rein historisch und basiert nicht auf Studien. Könnten Sie bitte Links zu Studien hinzufügen, um Ihre Meinung zu bestätigen?
Sulthan
Eine andere Frage hat diesen UX-Link bereits in den Kommentaren; Weitere Referenzen dort. Während die Zahl 80 selbst ein historischer Zufall ist, leitet sie sich grob aus der Anzahl der Striche pro Zeile auf Schreibmaschinen ab, die grob aus der üblichen Breite eines einspaltigen Drucks abgeleitet wurde und deren Durchschnitt von 66 Buchstaben seit langem Tradition hat.
Jan Hudec