Gibt es einen triftigen Grund eine maximale Breite von 80 Zeichen in einer Code-Datei für die Durchsetzung, an diesem Tag und Alter? [geschlossen]

https://stackoverflow.com/questions/110928

02-07-2019
|

Frage

Im Ernst. Auf einem 22" Monitor, es deckt nur vielleicht ein Viertel des Bildschirms. Ich brauche etwas Munition, diese Regel Axt.

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

Lösung

Ich denke, die Praxis-Code 80 (oder 79) Spalten zu halten ursprünglich Menschen geschaffen wurde auf 80-Säule Dumb-Terminals oder auf 80-Spalten-Ausdrucken Bearbeitung Code zu unterstützen. Diejenigen Anforderung haben meist weggegangen jetzt, aber es gibt immer noch gute Gründe, die 80 Spalte Regel zu halten:

Verpackung zu vermeiden, wenn der Code in E-Mail zu kopieren, Webseiten und Bücher.
Um mehr Quell Fenster Seite an Seite oder mit einem Side-by-Side-Diff-Viewer.
Lesbarkeit zu verbessern. Schmaler Code kann ohne schnell gelesen werden, die die Augen von Seite zu scannen zu Seite.

Ich glaube, der letzte Punkt ist das wichtigste. Obwohl Displays haben in Größe und Auflösung in den letzten Jahren stark gewachsen, Augen haben nicht .

Andere Tipps

Der Ursprung der 80-Spalten-Textformatierung ist älter als 80-Spalten-Terminals - die IBM Lochkartendaten zurück auf 1928 ! Das erinnert an die (apokryphen) Geschichte, dass die US-Eisenbahnspurweite bestimmt durch die Breite der Wagenräder im römischen Britannien.

ich es manchmal finde ein bisschen einschnürende, aber es macht Sinn zu haben, einige Standard-Limit, so 80 Spalten ist.

Hier ist das gleiche Thema bedeckt von Slashdot .

Und hier ist ein Old-School Fortran Statement:

80 Zeichen ist eine lächerliche Grenze in diesen Tagen. Teilen Sie Ihre Code-Zeilen, wo es sinnvoll ist, nicht nach einem beliebigen Zeichen.

Sie sollten es tun, nur um einen jeden, der nicht über einen 22-Zoll-Breitbild-Monitor verfügt. Persönlich arbeiten, ich auf einem 17-Zoll-4: 3-Monitor, und ich finde, dass mehr als ausreichend breit. Allerdings habe ich auch drei dieser Monitore, so dass ich noch viel nutzbaren Platz auf dem Bildschirm haben.

Nicht nur das, sondern das menschliche Auge hat tatsächlich Probleme beim Lesen Textes, wenn die Zeilen zu lang sind. Es ist zu einfach zu bekommen, in dem verloren Zeile Sie sich befinden. Die Zeitungen sind 17 Zoll über (oder wie das somethign), aber Sie sehen sie nicht über die Seite den ganzen Weg zu schreiben, gleiche gilt für Zeitschriften und andere Drucksachen. Es ist tatsächlich einfacher zu lesen, wenn Sie die Spalten schmal halten.

Druck eine nichtproportionalen Schrift auf Standardgrößen ist (auf A4-Papier) 80 Spalten mit 66 Zeilen.

Wenn Sie eine Folge von Anweisungen, die mit geringfügigen Abweichungen wiederholen kann es einfacher sein, die Ähnlichkeiten und Unterschiede zu sehen, ob die sie in Linien gruppiert werden, so dass die Unterschiede vertikal ausgerichtet werden.

Ich würde argumentieren, dass die folgende ist viel besser lesbar als es gewesen wäre, wenn ich es über mehrere Zeilen aufgeteilt würde:

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 dem Kommentar des es gewesen ist vorgeschlagen, dass dies ein prägnanter Weise sein würde, die oben 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 paßt glaube ich, mein Punkt steht noch und ich habe einfach ein schlechtes Beispiel. Es ist immer noch zeigen, dass auf einer Linie mehr Anweisungen Platzierung Lesbarkeit verbessern.

Ich verwende das den Vorteil, größerer Bildschirm mehrere Codestücke nebeneinander zu haben.

Sie werden keine Munition von mir. In der Tat, würde ich es da noch in Notfällen geändert, um zu sehen hasse ich selten sehen, wo ich Code aus einer Text-Konsole zu ändern.

Super-lange Linien sind schwerer zu lesen. Nur weil Sie 300 Zeichen über auf dem Monitor bekommen bedeutet nicht, sollten Sie die Linien machen so lange. 300 Zeichen sind auch viel zu komplex für eine Aussage, wenn Sie keine andere Wahl haben (einen Anruf, der eine ganze Reihe von Parametern benötigt.)

Ich benutze 80 Zeichen als eine allgemeine Regel, aber ich werde darüber hinaus gehen, wenn sie einen Zeilenumbruch setzte in einer unerwünschten Stelle würde bedeuten, durchzusetzen.

Das einzige, was ich innerhalb von 80 Zeichen bleiben erzwingen ist meine Kommentierung.

persönlich ... Ich widme mein Gehirn Macht (was wenig ist) zu Codierung rechts, dann ist es ein Schmerz zu haben, um alles zurück und brechen am 80 Zeichen Grenze, wenn ich meine Zeit auf verbringen könnte die nächste Funktion. Ja, ReSharper könnte es für mich tun nehme ich an, aber dann heraus, dass es Freaks mich ein wenig, dass eine dritte Partei Produktentscheidungen auf meinem Code-Layout machen und ändert sie ( „Bitte nicht brechen meinen Code in zwei Zeilen HAL. HAL?“ ).

Das heißt, ich auf einem ziemlich kleinen Team arbeiten und alle unsere Monitore sind ziemlich groß, so darum zu kümmern, was stört meine Kolleginnen und Programmierer ist nicht eine große Sorge, wie weit das geht.

Es scheint, obwohl einige Sprachen im Interesse von mehr bang for the buck (kurzer Hand, wenn dann Aussagen).

mehr Zeilen Code fördern

Ich habe zwei 20" 1600x1200 Monitore und ich bleibe zu 80 Spalten, weil es mir mehrere Texteditorfenster Seite-an-Seite anzeigen können. Mit Hilfe der ‚6x13‘ font (die trad. Xterm Schrift) 80 Spalten aufnehmen 480 Pixel plus die Scrollbar und Fensterrahmen. diese drei Fenster dieser Art auf einem 1600x1200-Monitor haben kann. Unter Windows der Schriftart Lucida Console wird nicht ganz das tun (die minimun nutzbare Größe ist 7 Pixel breit), aber ein 1280x1024-Monitor erscheint zwei Säulen und ein 1920x1200-Monitor wie ein HP LP2465 angezeigt wird 3. Es wird auch ein bisschen Platz auf der Seite für den verschieden Explorer, Eigenschaften und andere Fenster von Visual Studio verlassen.

Darüber hinaus sehr lange Textzeilen sind schwer zu lesen. Für Text ist die optimale 66 Zeichen. Es gibt einen Punkt, an dem zu lange Identifikatoren kontraproduktiv zu sein beginnen, weil sie es schwer zu legen Code kohärent zu machen. Gutes Layout und Vertiefung bietet visuelle Hinweise in Bezug auf die Code-Struktur und einige Sprachen (Python in den Sinn kommt) verwenden Einzug explizit für diese.

Um jedoch die Standard-Klassenbibliotheken für Java und .Net sind in der Regel ein Übergewicht von sehr langen Kennungen haben, so man nicht unbedingt garantiert Lage sein, dies zu tun. In diesem Fall hilft Auslegen Code mit Zeilenumbrüchen noch die Struktur explizit zu machen.

Beachten Sie, dass Sie Windows-Versionen von '6x13' Schriftarten Hier erhalten können.

Die anderen Antworten schon Dinge zusammengefasst schön, aber es ist auch eine Überlegung wert, wenn Sie kopieren möchten und einige Codes in eine E-Mail einfügen, oder wenn nicht Code dann ein diff.

Das ist eine Zeit, als eine „maximale Breite“ mit nützlich ist.

Sie sind nicht die einzige Person, die den Code halten wird.

Die nächste Person, die einen 17" Bildschirm hat möglicherweise oder möglicherweise große Schriften müssen den Text zu lesen. Die Grenze muss irgendwo sein und 80 Zeichen ist die Konvention aufgrund vorherigen Bildschirm Einschränkungen. Können Sie sich einen neuen Standard denken ( 120) und warum es eine gute Idee ist, dass andere zu verwenden, dann „das ist, was bei Xpt Schrift auf meinen Monitor paßt?“

Denken Sie daran, es gibt immer Ausnahmen zu jeder Regel, so dass es Sie eine bestimmte Zeile oder einen Block von Code, der Sinn mehr als 80 Zeichen dann ein Rebell sein macht.

Aber die Zeit nehmen, zuerst zu denken „ist dieser Code wirklich so schlimm, dass es nicht innerhalb von 80 Zeichen leben kann?“

In dem Linux-Codierungsstandard, nicht nur halten sie die 80 Zeichen begrenzt, sondern sie auch 8 Raum Einzug verwenden.

Ein Teil der Argumentation ist, dass, wenn Sie jemals den rechten Rand erreichen, sollten Sie eine Einzugsebene in eine separate Funktion betrachten zu bewegen.

Dies wird klarer Code machen, weil unabhängig von Einbuchtung Längen, ist es schwieriger, Code mit vielen verschachtelten Kontrollstrukturen zu lesen.

Ich frage mich, ob dies mehr Probleme in der heutigen Zeit verursachen könnten. Denken Sie daran, dass in C (und möglicherweise auch andere Sprachen) gibt es Regeln, wie lange ein Funktionsname sein kann. Daher sehen Sie oft sehr schwer zu verstehende Namen in C-Code. Die gute Sache ist, dass sie nicht viel Platz verwenden. Aber jedes Mal, wenn ich in einer Sprache an Code aussehen wie C # oder Java der Methodennamen sind oft sehr lang, was es fast unmöglich macht den Code zu halten, bei einer 80 Zeichen Länge. Ich glaube nicht, 80 Zeichen heute gültig sind, es sei denn, Sie den Code drucken müssen in der Lage sein, etc.

Wie andere gesagt haben, ich glaube, es ist am besten für (1) Druck und (2) Anzeige mehrerer Dateien nebeneinander in vertikaler Richtung.

Ich mag meine Breite zu 100 Zeichen beschränken oder so zwei SxS-Editoren auf einem Widescreen-Monitor zu ermöglichen. Ich glaube nicht, dass es mehr für eine Grenze von genau 80 Zeichen ein guter Grund ist.

aus 100 Zeichen

Ich habe meinen Code erweitert, die in weniger als einer halben meinem Bildschirm auf meinem MacBook passt bequem. 120 Zeichen sind wahrscheinlich die Grenze vor Linien zu lang und komplex zu erhalten beginnen. Sie wollen nicht zu weit zu bekommen, was Sie zusammengesetzte Anweisungen fördern und tief verschachtelte Kontrollstrukturen.

Der rechte Rand ist der natürliche Weg, Ihnen zu sagen, ein zusätzliche Methode Refactoring auszuführen .

Verwenden Sie proportionale Schriftarten.

Ich bin ernst. Ich kann in der Regel die Äquivalenz von 100-120 Zeichen in einer Zeile erhalten, ohne die Lesbarkeit oder Bedruckbarkeit zu opfern. In der Tat ist es noch einfacher, mit einer guten Schrift zu lesen (zum Beispiel Verdana) und Syntaxfärbung. Es sieht ein wenig seltsam für ein paar Tage, aber Sie schnell daran gewöhnen.

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

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Das ist 94 Zeichen lang sein und der Klassenname ist ziemlich kurz (von GWT-Standards). Es wäre schwierig, auf 2 Zeilen zu lesen, und es ist sehr gut lesbar auf einer Linie. Pragmatisch darüber und so dass „Rückwärtskompatibilität“, ich 100 Zeichen sagen würde, ist die richtige Breite.

Wie der Autor von Leitlinien für meinen Arbeitgeber Codierung ich die Zeilenlänge von 80 bis 132 upped haben Warum dieser Wert? Nun, wie andere darauf hingewiesen, 80 ist die Länge vieler alter Hardware-Terminals. Und 132 ist, wie gut! Es ist die Linienbreite, wenn Terminals sind in Wide-Modus . Jeder Drucker könnte auch machen Hardcopies in weitem Modus mit einem kondensierten Schriftart.

Der Grund für die nicht bei 80 bleibt, ist, dass ich lieber

bevorzugen längere Namen mit Bedeutung für Bezeichner
nicht mit typedefs für structs und Aufzählungen in C Mühe (sie schlecht sind, sie nützliche Informationen verst Stellen Sie Peter van der Linden in „Deep C Secrets“, wenn Sie es nicht glauben), so dass der Code mehr struct FOO func(struct BAR *aWhatever, ...) hat als Code von typedef Fanatiker.

und unter diesen Regeln nur 80 Zeichen / Zeile Ursache hässliche Zeile mehr hüllen oft als meine Augen halten akzeptabel (meist in Prototypen und Funktionsdefinitionen).

Ich versuche, die Dinge aus einem einfachen Grunde in der Nähe von 80 Zeichen zu halten: zu viel mehr als das bedeutet, mein Code zu kompliziert wird immer. Übermäßig ausführliche Eigenschaft / Methodennamen, Klassennamen usw. so viel Schaden wie terse diejenigen führen.

Ich bin in erster Linie ein Python-Codierer, so erzeugt dies zwei Sätze von Einschränkungen:

Schreiben Sie nicht lange Zeilen Code
Einzug nicht zu viel

Wenn Sie erreichen zwei oder drei Ebenen der Vertiefung beginnen, Ihre Logik wird verwirrend. Wenn Sie nicht einen einzigen Block auf der gleichen Seite halten, Ihr Code wird immer zu kompliziert und schwierig zu erinnern. Wenn Sie nicht eine einzige Zeile innerhalb von 80 Zeichen halten, Ihre Linie wird immer zu kompliziert.

Es ist in Python einfach relativ kurzen Code zu schreiben (siehe codegolf) auf Kosten der Lesbarkeit, aber es ist noch einfacher zu ausführlichem Code auf Kosten der Lesbarkeit zu schreiben. Hilfsmethoden sind keine schlechte Sache, noch sind Hilfsklassen. Übermäßige Abstraktion kann ein Problem sein, aber das ist eine andere Herausforderung der Programmierung.

Wenn im Zweifel in einer Sprache wie Helferfunktionen C Schreib- und sie inline, wenn Sie den Aufwand nicht wollen, auf eine andere Funktion aufzurufen und springt zurück. In den meisten Fällen wird der Compiler Dinge behandeln intelligent für Sie.

Es gibt bereits viele gute Antworten auf diese, aber es ist erwähnenswert, dass in der IDE Sie eine Liste der Dateien auf der linken Seite haben könnte, sowie eine Liste der Funktionen auf der rechten Seite (oder jede andere Konfiguration).

Sie sind Code nur ein Teil der Umwelt ist.

ich, was 80 Zeichen nicht erzwingen bedeutet schließlich Zeilenumbruch.
IMO, eine beliebige Länge für eine max-width Linie gewählt ist nicht immer angemessen und Zeilenumbruch sollte eine mögliche Antwort sein.
Und das ist nicht so einfach wie es klingt.

Es wird umgesetzt in jedit
_{(Quelle: jedit.org )} der Zeilenumbruch bietet

Aber es ist bitter in Eclipse von einem looong Zeit verpasst ! (Seit 2003 in der Tat), vor allem, weil ein Zeilenumbruch für Texteditor rel="nofollow beinhaltet:

Wrapped Online-Informationen sind für den Text-Viewer, Code-Navigation, die vertikale Lineal.
Unwrapped Linie Informationen für Funktionen wie goto Linie erforderlich, Zeilenlineal Spalte Nummerierung, aktuelle Zeile markieren, Speichern der Datei.

Ich folge tatsächlich einer ähnliche Regel für meinen eigenen Code, sondern nur wegen des Druckcode auf eine A4-Seite - 80 Spalten ist über die richtige Breite für meine gewünschte Schriftgröße

Aber das ist persönliche Präferenz und wahrscheinlich nicht das, was Sie waren nach (da Sie Munition in die andere Richtung gehen wollen).

Was Sie nicht in Frage stellen, die Argumentation hinter der Grenze - ernst, wenn niemand mit einem guten Grunde kommen kann, warum es so, Sie einen guten Fall haben dafür, dass es von Ihren Coding-Standards entfernt

Ich bin diffing Seite an Seite den ganzen Tag und ich habe nicht ein freakin 22-Zoll-Monitor. Ich weiß nicht, ob ich jemals wird. Dies ist natürlich nur von geringem Interesse Programmierer zu schreiben geschützten Pfeil-Codierung und 300 Zeichen Linien zu genießen.

Ja, denn auch in der heutigen Zeit, einige von uns Codierung an den Klemmen (ok, meist Terminal-Emulatoren), wo die Anzeige kann nur 80 Zeichen angezeigt werden. Also, zumindest für die Codierung ich tun, ich schätze die 80 char Regel.

Ich denke immer noch, dass die Grenze nicht auf dem visuellen Teil begrenzt ist. Sicher, die Monitore und Auflösungen sind groß genug, um noch mehr Zeichen heutzutage in einer Zeile zu zeigen, aber nicht erhöht es die Lesbarkeit?

Wenn die Grenze wirklich erzwungen es ist auch ein guter Grund, den Code zu überdenken und nicht alles in eine Zeile zu setzen. Es ist das gleiche mit Einbuchtung -., Wenn Sie viele Ebene Code müssen neu gedacht werden muss,

bei 80 Zeichen Brechen ist etwas, was Sie tun, während Codierung, nicht danach. Das Gleiche gilt für Kommentare, natürlich. Die meisten Editoren können Sie zu sehen, helfen, wo die 80-Zeichen Grenze ist.

(Dies kann ein wenig OT, aber in Eclipse gibt es eine Option, die die Code-Formate beim Speichern (nach was auch immer Regeln, die Sie wollen). Dies ist ein wenig auf dem ersten freaky, aber nach einer Weile beginnen Sie akzeptieren, dass die Formatierung nicht mehr in den Händen ist als der generierte Code ist.)

Wenn wir einen von diese , würden wir nicht sein, diese Diskussion mit! ; -)

Aber ernsthaft die Probleme, die Menschen in ihren Antworten erhoben haben, sind durchaus legitim. Doch das ursprüngliche Plakat wurde nicht an einer Grenze streiten, nur dass 80 Spalten zu wenig sind.

Das Thema E-Mail Code-Schnipsel hat einen gewissen Wert. Aber die bösen Faktoren berücksichtigt, dass die meisten E-Mail-Clients vorformatiert tun, um Text denke ich, dass der Zeilenumbruch ist nur eines Ihrer Probleme.

Wie für den Druck Normalerweise finde ich, dass 100 Zeichen Linien sehr passen bequem auf einer gedruckten Seite.

Ich versuche, und halte meine Linien unter 80 Spalten. Der stärkste Grund ist, dass ich mich oft finden grep und less mit meinem Code zu durchsuchen, wenn auf der Kommandozeile arbeiten. Ich mag wirklich nicht, wie Terminals lange Versorgungsleitungen brechen (sie doch nicht für diesen Job gemacht). Ein weiterer Grund ist, dass ich finde, es sieht besser aus, wenn alles in die Zeile passt und nicht vom Herausgeber gebrochen. Beispielsweise Parameter von langFunktion Anrufe untereinander und ähnliche Dinge gut ausgerichtet sind.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow