Gibt es heutzutage einen gültigen Grund für die Durchsetzung einer maximalen Breite von 80 Zeichen in einer Codedatei? [geschlossen]

Ernsthaft. Auf einem 22-Zoll-Monitor deckt er nur ein Viertel des Bildschirms ab. Ich benötige etwas Munition, um diese Regel zu umgehen.

Ich sage nicht, dass es keine Grenze geben sollte; Ich sage nur, 80 Zeichen sind sehr klein.

Ich denke, die Praxis, Code auf 80 (oder 79) Spalten zu belassen, wurde ursprünglich entwickelt, um die Bearbeitung von Code auf dummen Terminals mit 80 Spalten oder auf Ausdrucken mit 80 Spalten zu unterstützen. Diese Anforderungen sind jetzt größtenteils weg, aber es gibt immer noch triftige Gründe, die 80-Spalten-Regel beizubehalten:

• Um ein Umbrechen beim Kopieren von Code in E-Mails, Webseiten und Bücher zu vermeiden.
• Anzeigen mehrerer Quellfenster nebeneinander oder Verwenden eines Diff-Viewers nebeneinander.
• Zur Verbesserung der Lesbarkeit. Schmaler Code kann schnell gelesen werden, ohne dass Sie Ihre Augen von einer Seite zur anderen scannen müssen.

Ich denke, der letzte Punkt ist der wichtigste. Obwohl die Größe und Auflösung der Displays in den letzten Jahren zugenommen hat, haben die Augen dies nicht getan .

Der Ursprung der 80-Spalten-Textformatierung liegt vor den 80-Spalten-Terminals - die IBM Lochkarte stammt aus dem Jahr 1928 ! Dies erinnert an die (apokryphe) Geschichte, dass die US-Eisenbahnspur durch die Breite der Wagenräder im römischen Großbritannien bestimmt wurde.

Ich finde es manchmal etwas einschränkend, aber es ist sinnvoll, ein Standardlimit zu haben , also 80 Spalten.

Hier ist das gleiche Thema, das von Slashdot behandelt wird .

Und hier ist eine Fortran-Erklärung der alten Schule:

80 Zeichen sind heutzutage eine lächerliche Grenze. Teilen Sie Ihre Codezeilen dort auf, wo es sinnvoll ist, und nicht nach einer beliebigen Zeichenbeschränkung.

Sie sollten es nur für alle tun, die keinen 22-Zoll-Breitbildmonitor haben. Persönlich arbeite ich an einem 17-Zoll-4: 3-Monitor und finde das mehr als ausreichend breit. Ich habe jedoch auch 3 dieser Monitore, so dass ich immer noch viel nutzbaren Bildschirmplatz habe.

Darüber hinaus hat das menschliche Auge tatsächlich Probleme beim Lesen von Text, wenn die Zeilen zu lang sind. Es ist zu leicht, sich in der Linie zu verlieren, in der Sie sich befinden. Zeitungen haben einen Durchmesser von 17 Zoll (oder so ähnlich), aber Sie sehen nicht, dass sie den ganzen Weg über die Seite schreiben. Gleiches gilt für Zeitschriften und andere gedruckte Artikel. Es ist tatsächlich einfacher zu lesen, wenn Sie die Spalten schmal halten.

Wenn Sie eine Folge von Anweisungen haben, die sich mit geringfügigen Abweichungen wiederholen, können Sie die Ähnlichkeiten und Unterschiede leichter erkennen, wenn sie in Linien gruppiert sind, sodass die Unterschiede vertikal ausgerichtet sind.

Ich würde argumentieren, dass das Folgende viel besser lesbar ist, als es gewesen wäre, wenn ich es auf mehrere Zeilen aufgeteilt hätte:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

Update: In den Kommentaren wurde vorgeschlagen, dass dies eine prägnantere Methode wäre, um Folgendes zu tun:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

Obwohl es jetzt in 80 Spalten passt, denke ich, dass mein Standpunkt immer noch besteht und ich gerade ein schlechtes Beispiel ausgewählt habe. Es zeigt immer noch, dass das Platzieren mehrerer Anweisungen in einer Zeile die Lesbarkeit verbessern kann.

Das Drucken einer monospaced Schriftart in Standardgrößen beträgt (auf A4-Papier) 80 Spalten x 66 Zeilen.

Ich nutze den Vorteil größerer Bildschirme, um mehrere Codeteile nebeneinander zu haben.

Du wirst keine Munition von mir bekommen. Tatsächlich würde ich es hassen, wenn sich das ändern würde, da ich in Notfällen immer noch seltene Fälle sehe, in denen ich Code von einer Textkonsole aus ändern muss.

Superlange Zeilen sind schwerer zu lesen. Nur weil Sie 300 Zeichen auf Ihrem Monitor anzeigen können, heißt das nicht, dass Sie die Zeilen so lang machen sollten. 300 Zeichen sind auch viel zu komplex für eine Anweisung, es sei denn, Sie haben keine Wahl (ein Aufruf, der eine ganze Reihe von Parametern benötigt.)

Ich verwende in der Regel 80 Zeichen, aber ich werde darüber hinausgehen, wenn das Erzwingen einen Zeilenumbruch an einer unerwünschten Stelle bedeuten würde.

Das einzige, was ich erzwinge, um innerhalb von 80 Zeichen zu bleiben, ist mein Kommentar.

Persönlich ... Ich widme meine ganze Gehirnleistung (was wenig da ist) dem richtigen Codieren. Es ist ein Schmerz, zurück zu gehen und alles bei der 80-Zeichen-Grenze aufzubrechen, wenn ich meine Zeit für die nächste Funktion verbringen könnte . Ja, Resharper könnte es für mich tun, aber dann macht es mir ein wenig Angst, dass ein Produkt eines Drittanbieters Entscheidungen über mein Codelayout trifft und es ändert ("Bitte teilen Sie meinen Code nicht in zwei Zeilen auf HAL. HAL?" ).

Trotzdem arbeite ich in einem ziemlich kleinen Team und alle unsere Monitore sind ziemlich groß. Die Sorge darüber, was meine Programmierkollegen stört, ist in dieser Hinsicht kein großes Problem.

Scheint, als ob einige Sprachen längere Codezeilen fördern, um mehr Geld zu verdienen (kurze Hand, wenn dann Aussagen).

Ich habe zwei 20 "1600x1200-Monitore und halte mich an 80 Spalten, da ich mehrere Texteditorfenster nebeneinander anzeigen kann. Bei Verwendung der Schriftart '6x13' (die traditionelle xterm-Schriftart) nehmen 80 Spalten 480 Pixel plus Bildlaufleiste ein Dies ermöglicht es einem, drei Fenster dieses Typs auf einem 1600x1200-Monitor zu haben. Unter Windows wird die Lucida Console-Schriftart dies nicht ganz tun (die minimal verwendbare Größe ist 7 Pixel breit), aber ein 1280x1024-Monitor zeigt zwei Spalten und an Auf einem 1920 x 1200-Monitor wie einem HP LP2465 wird 3 angezeigt. Außerdem bleibt an der Seite etwas Platz für die verschiedenen Explorer-, Eigenschaften- und anderen Fenster von Visual Studio.

Außerdem sind sehr lange Textzeilen schwer zu lesen. Für Text ist das Optimum 66 Zeichen. Es gibt einen Punkt, an dem übermäßig lange Bezeichner kontraproduktiv werden, weil sie es schwierig machen, Code kohärent zu gestalten. Gutes Layout und Einrückung liefern visuelle Hinweise auf die Codestruktur, und einige Sprachen (Python fällt mir ein) verwenden hierfür ausdrücklich Einrückungen.

Die Standardklassenbibliotheken für Java und .Net weisen jedoch in der Regel sehr lange Bezeichner auf, sodass nicht unbedingt garantiert werden kann, dass dies möglich ist. In diesem Fall hilft das Anlegen von Code mit Zeilenumbrüchen immer noch, die Struktur explizit zu machen.

Beachten Sie, dass Sie Windows - Versionen von ‚6x13‘ Schriftarten bekommen hier .

Die Leute sagen, lange Codezeilen seien in der Regel komplex. Betrachten Sie eine einfache Java-Klasse:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Dies ist 94 Zeichen lang und der Klassenname ist ziemlich kurz (für GWT-Standards). Es wäre schwierig, in zwei Zeilen zu lesen, und es ist in einer Zeile sehr gut lesbar. Da es pragmatisch ist und somit "Abwärtskompatibilität" ermöglicht, würde ich sagen, dass 100 Zeichen die richtige Breite haben.

Die anderen Antworten haben die Dinge bereits gut zusammengefasst, aber es lohnt sich auch zu überlegen, wann Sie Code kopieren und in eine E-Mail einfügen möchten, oder wenn nicht, dann einen Unterschied.

Dies ist eine Zeit, in der eine "maximale Breite" nützlich ist.

Sie sind nicht die einzige Person, die Ihren Code pflegen wird.

Die nächste Person, die dies tut, hat möglicherweise einen 17-Zoll-Bildschirm oder benötigt möglicherweise große Schriftarten, um den Text zu lesen. Das Limit muss irgendwo liegen und 80 Zeichen sind die Konvention aufgrund früherer Bildschirmbeschränkungen. Können Sie sich einen neuen Standard vorstellen (120) und Warum ist es eine gute Idee, diese andere als "das passt auf meinen Monitor mit Xpt-Schriftart?"

Denken Sie daran, dass es zu jeder Regel immer Ausnahmen gibt, sodass Sie eine bestimmte Zeile oder einen bestimmten Codeblock haben, die sinnvoll sind, mehr als 80 Zeichen zu haben und dann ein Rebell zu sein.

Aber nehmen Sie sich zuerst die Zeit zu überlegen: "Ist dieser Code wirklich so schlecht, dass er nicht innerhalb von 80 Zeichen leben kann?"

Im Linux-Codierungsstandard behalten sie nicht nur die Beschränkung auf 80 Zeichen bei, sondern verwenden auch Einrückungen mit 8 Leerzeichen.

Ein Teil der Argumentation ist, dass Sie in Betracht ziehen sollten, eine Einrückungsstufe in eine separate Funktion zu verschieben, wenn Sie jemals den richtigen Rand erreichen.

Dadurch wird der Code klarer, da es unabhängig von den Einrückungslängen schwieriger ist, Code mit vielen verschachtelten Steuerstrukturen zu lesen.

Ich habe meinen Code auf 100 Zeichen erweitert, was bequem in weniger als die Hälfte meines Bildschirms auf meinem Macbook passt. 120 Zeichen sind wahrscheinlich die Grenze, bevor die Zeilen zu lang und komplex werden. Sie möchten nicht zu weit gehen, sonst fördern Sie zusammengesetzte Anweisungen und tief verschachtelte Kontrollstrukturen.

Der rechte Rand ist die Art und Weise, wie die Natur Sie auffordert, ein zusätzliches Methoden-Refactoring durchzuführen .

Ich frage mich, ob dies heutzutage mehr Probleme verursachen könnte. Denken Sie daran, dass es in C (und möglicherweise in anderen Sprachen) Regeln gibt, wie lange ein Funktionsname sein kann. Daher werden im C-Code häufig sehr schwer verständliche Namen angezeigt. Das Gute ist, dass sie nicht viel Platz beanspruchen. Aber jedes Mal, wenn ich Code in einer Sprache wie C # oder Java betrachte, sind die Methodennamen oft sehr lang, was es nahezu unmöglich macht, Ihren Code auf einer Länge von 80 Zeichen zu halten. Ich glaube nicht, dass heute 80 Zeichen gültig sind, es sei denn, Sie müssen in der Lage sein, den Code usw. zu drucken.

Als Autor der Kodierungsrichtlinien für meinen Arbeitgeber habe ich die Zeilenlänge von 80 auf 132 erhöht. Warum dieser Wert? Nun, wie andere betonten, ist 80 die Länge vieler alter Hardware-Terminals. Und 132 ist auch! Dies ist die Linienbreite, wenn sich die Terminals im Breitbildmodus befinden . Jeder Drucker kann auch Hardcopies im Breitbildmodus mit einer komprimierten Schriftart erstellen.

Der Grund, nicht bei 80 zu bleiben, ist, dass ich eher

• bevorzugen längere Namen mit einer Bedeutung für Bezeichner
• Machen Sie sich keine Gedanken über Typedefs für Strukturen und Aufzählungen in C (sie sind SCHLECHT, sie verbergen nützliche Informationen! Fragen Sie Peter van der Linden in "Deep C Secrets", wenn Sie es nicht glauben), sodass der Code mehr struct FOO func(struct BAR *aWhatever, ...)als nur Code von Typedef-Fanatikern enthält .

und nach diesen Regeln verursachen nur 80 Zeichen / Zeile häufiger hässliche Zeilenumbrüche, als meine Augen für akzeptabel halten (meistens in Prototypen und Funktionsdefinitionen).

Wie andere gesagt haben, ist es meiner Meinung nach am besten, (1) mehrere Dateien nebeneinander vertikal zu drucken und (2) anzuzeigen.

Ich möchte meine Breite auf etwa 100 Zeichen beschränken, um zwei SxS-Editoren auf einem Breitbildmonitor zuzulassen. Ich glaube nicht, dass es einen guten Grund mehr für ein Limit von genau 80 Zeichen gibt.

Verwenden Sie proportionale Schriftarten.

Es ist mein ernst. Normalerweise kann ich die Äquivalenz von 100-120 Zeichen in einer Zeile erhalten, ohne die Lesbarkeit oder Druckbarkeit zu beeinträchtigen. Mit einer guten Schriftart (z. B. Verdana) und Syntaxfarbe ist das Lesen sogar noch einfacher. Es sieht für ein paar Tage etwas seltsam aus, aber man gewöhnt sich schnell daran.

Ich versuche aus einem einfachen Grund, die Anzahl der Zeichen auf 80 zu beschränken: Zu viel mehr bedeutet, dass mein Code zu kompliziert wird. Übermäßig ausführliche Eigenschafts- / Methodennamen, Klassennamen usw. verursachen ebenso viel Schaden wie knappe.

Ich bin in erster Linie ein Python-Codierer, daher ergeben sich zwei Einschränkungen:

1. Schreiben Sie keine langen Codezeilen
2. Nicht zu viel einrücken

Wenn Sie zwei oder drei Einrückungsstufen erreichen, wird Ihre Logik verwirrend. Wenn Sie nicht einen einzelnen Block auf derselben Seite behalten können, wird Ihr Code zu kompliziert und schwierig, um ihn sich zu merken. Wenn Sie eine einzelne Zeile nicht innerhalb von 80 Zeichen halten können, wird Ihre Zeile zu kompliziert.

In Python ist es einfach, relativ präzisen Code (siehe Codegolf) auf Kosten der Lesbarkeit zu schreiben, aber es ist noch einfacher, ausführlichen Code auf Kosten der Lesbarkeit zu schreiben. Hilfsmethoden sind weder eine schlechte Sache noch Hilfsklassen. Übermäßige Abstraktion kann ein Problem sein, aber das ist eine weitere Herausforderung bei der Programmierung.

Wenn Sie Zweifel an einer Sprache wie C haben, schreiben Sie Hilfsfunktionen und fügen Sie sie ein, wenn Sie nicht den Aufwand haben möchten, eine andere Funktion aufzurufen und zurückzuspringen. In den meisten Fällen erledigt der Compiler die Dinge intelligent für Sie.

Es gibt bereits viele gute Antworten darauf, aber es ist erwähnenswert, dass Sie in Ihrer IDE möglicherweise eine Liste der Dateien links und eine Liste der Funktionen rechts (oder eine andere Konfiguration) haben.

Ihr Code ist nur ein Teil der Umgebung.

Wenn ich 80 Zeichen nicht erzwinge, bedeutet dies schließlich, dass Wörter umbrochen werden.
IMO, jede Länge, die für eine Linie mit maximaler Breite gewählt wird, ist nicht immer angemessen, und der Zeilenumbruch sollte eine mögliche Antwort sein.
Und das ist nicht so einfach, wie es sich anhört.

Es ist in jedit _{(Quelle: jedit.org )} implementiert, das _{Zeilenumbruch} bietet

Aber es wird in der Finsternis von einer langen Zeit bitter vermisst ! (seit 2003), hauptsächlich, weil ein Zeilenumbruch für den Texteditor Folgendes beinhaltet:

• Umbrochene Zeileninformationen sind für den Textbetrachter, die Code-Navigation und vertikale Lineale bestimmt.
• Unverpackte Zeileninformationen sind für Funktionen wie "Gehe zu Zeile", "Linienspalte für die Zeilennummerierung", "Aktuelle Zeilenhervorhebung" und "Speichern der Datei" erforderlich.

Ich befolge tatsächlich eine ähnliche Regel für meinen eigenen Code, aber nur, weil Code auf eine A4-Seite gedruckt wird - 80 Spalten entsprechen ungefähr der richtigen Breite für meine gewünschte Schriftgröße.

Aber das ist eine persönliche Präferenz und wahrscheinlich nicht das, wonach Sie gesucht haben (da Sie möchten, dass Munition in die andere Richtung geht).

Was hinterfragen Sie nicht die Gründe für das Limit? Im Ernst, wenn niemand einen guten Grund dafür finden kann, haben Sie ein gutes Argument dafür, dass es aus Ihren Codierungsstandards entfernt wird.

Ich bin den ganzen Tag Seite an Seite und habe keinen verdammten 22-Zoll-Monitor. Ich weiß nicht, ob ich jemals werde. Dies ist natürlich für Nur-Schreib-Programmierer, die Pfeilcodierung und 300-Zeichen-Zeilen genießen, von geringem Interesse.

Ja, denn selbst in der heutigen Zeit codieren einige von uns auf Terminals (ok, meistens Terminalemulatoren), auf denen auf dem Display nur 80 Zeichen angezeigt werden können. Zumindest für die Codierung, die ich mache, schätze ich die 80-Zeichen-Regel sehr.

Ich denke immer noch, dass das Limit nicht auf den visuellen Teil beschränkt ist. Sicher, die Monitore und Auflösungen sind heutzutage groß genug, um noch mehr Zeichen in einer Zeile anzuzeigen, aber erhöht dies die Lesbarkeit?

Wenn das Limit wirklich durchgesetzt wird, ist es auch ein guter Grund, den Code zu überdenken und nicht alles in eine Zeile zu setzen. Das Gleiche gilt für Einrückungen. Wenn Sie zu viele Ebenen benötigen, muss Ihr Code überdacht werden.

Das Brechen mit 80 Zeichen ist etwas, was Sie beim Codieren tun , nicht danach. Das gleiche gilt natürlich für Kommentare. Die meisten Editoren können Ihnen dabei helfen, festzustellen, wo das Limit von 80 Zeichen liegt.

(Dies mag ein wenig OT sein, aber in Eclipse gibt es eine Option, die den Code beim Speichern formatiert (nach den von Ihnen gewünschten Regeln). Dies ist zunächst etwas ausgeflippt, aber nach einer Weile beginnen Sie zu akzeptieren, dass der Die Formatierung liegt nicht mehr in Ihren Händen als der generierte Code.)

Wenn wir eine davon hätten , würden wir diese Diskussion nicht führen! ;-);

Aber im Ernst, die Themen, die die Leute in ihren Antworten angesprochen haben, sind ziemlich legitim. Das Originalplakat sprach sich jedoch nicht gegen eine Begrenzung aus, nur dass 80 Spalten zu wenig sind.

Das Problem des Versendens von Codefragmenten per E-Mail hat einige Vorteile. Aber angesichts der bösen Dinge, die die meisten E-Mail-Clients mit vorformatiertem Text tun, denke ich, dass Zeilenumbruch nur eines Ihrer Probleme ist.

Beim Drucken finde ich normalerweise, dass 100 Zeichenzeilen sehr bequem auf eine gedruckte Seite passen.

Ich versuche, meine Zeilen unter 80 Spalten zu halten. Der stärkste Grund ist, dass ich häufig meinen Code benutze grepund lessdurchsuche, wenn ich über die Befehlszeile arbeite. Ich mag es wirklich nicht, wie Terminals lange Quellleitungen unterbrechen (sie sind schließlich nicht für diesen Job gemacht). Ein weiterer Grund ist, dass ich finde, dass es besser aussieht, wenn alles in die Zeile passt und nicht vom Editor unterbrochen wird. Zum Beispiel mit Parametern von langen Funktionsaufrufen, die gut untereinander ausgerichtet sind, und ähnlichen Dingen.