Beschränkt ihr euch beim Progammieren auf maximal 80 Zeichen pro Zeile?

nein

volkard schrieb:

Praktiker schrieb:

Also ich nutzte > 80 Zeichen meist deswegen, weil man so Bequem Kommentare mit // anhängen kann und dann trotzdem bei Bedarf im Fall der Fälle, den gesamten Codeblock mit /* / wieder kommentieren kann, was ja umständlich ist, wenn man für die echten Kommentare / */ verwendet hat.

Tja und // funktioniert halt leider nur in einer Zeile, deswegen darf die dann auch länger werden, damit ich nicht so viele // in jede Zeile setzen muß.
//<ironie>Ja, das hat was für sich. Weil / auf der Tastatur total schwer zu finden ist, sollte man es nicht so oft drücken müssen. Über den Quelltext scrollen kann man ja zum Glück auch mit der Maus. KOmmetare werden so zwar etwas länger, das macht aber nichts, denn lesen will die in Wirklichkeit eh keiner. Ich lese sie ja auch nicht. Dadurch sagen sie auch immer wieder was ganz anderes aus, als im Code steht. ber egal. Wenn sich jemand beschwert, kann ich ihn ja fragen, weshalb er überhaupt Sachen liest, die so weit außerhalb des Bildschirms sind, und ob ihn das überhaupt was angeht. Zum Drucken paste ich den Code dann erst in den Internet-Explorer, weil der die rechten Überhänge so gut abschneiden kann. Also ich fahre sehr gut damit.</ironie>

1. Ich nutze ein US Tastaturlayout, daher ist / sehr gut zu erreichen.
2. ich sagte nicht, daß ich über den Bildschirm hinaus schreibe, so wie du das im Beispiel machst.
Ich nutze einfach 140 Zeichen anstatt nur 80, weil die trotzdem noch alle auf einmal ins Editorfenster passen ohne daß ich horizontal scrollen muß.
Und wenn dann kein Platz mehr ist, dann mach ich ne neue Zeile, setze wieder
ein // davor und gut ist.
3. Und bei all dieser Technik kann ich dann bei Bedarf trotzdem mit /* */ mal schnell nen ganzen Codeblock kommentieren, so daß der nicht zur Ausführung kommt.

otze

Ich benutze ca 90, das ist in etwa die Länge, die ich als angenehm empfinde. Das ist aber keine feste Regel, bei Funktionsdeklarationen habe ich auch kein Problem, über die 100 hinaus zu gehen, insbesondere weil die Typdeklarationen gerne etwas mehr Zeilen fressen, auch ganz ohne Templatemagie. "const std::vector<RealVector>&" wie es in meinem Projekt häufiger vorkommt sind bereits 30 Zeichen. Und die Dinger kommen immer in Paaren. noch gescheite Namen dazu und schwupps, die 80 sind voll. Und das obwohl eigentlich noch gar nichts kognitiv anstrengendes passiert ist.

volkard schrieb:

Praktiker schrieb:

Also ich nutzte > 80 Zeichen meist deswegen, weil man so Bequem Kommentare mit // anhängen kann und dann trotzdem bei Bedarf im Fall der Fälle, den gesamten Codeblock mit /* / wieder kommentieren kann, was ja umständlich ist, wenn man für die echten Kommentare / */ verwendet hat.

Tja und // funktioniert halt leider nur in einer Zeile, deswegen darf die dann auch länger werden, damit ich nicht so viele // in jede Zeile setzen muß.
//<ironie>Ja, das hat was für sich. Weil / auf der Tastatur total schwer zu finden ist, sollte man es nicht so oft drücken müssen. Über den Quelltext scrollen kann man ja zum Glück auch mit der Maus. KOmmetare werden so zwar etwas länger, das macht aber nichts, denn lesen will die in Wirklichkeit eh keiner. Ich lese sie ja auch nicht. Dadurch sagen sie auch immer wieder was ganz anderes aus, als im Code steht. ber egal. Wenn sich jemand beschwert, kann ich ihn ja fragen, weshalb er überhaupt Sachen liest, die so weit außerhalb des Bildschirms sind, und ob ihn das überhaupt was angeht. Zum Drucken paste ich den Code dann erst in den Internet-Explorer, weil der die rechten Überhänge so gut abschneiden kann. Also ich fahre sehr gut damit.</ironie>

Walli

Nein, ich breche so um wie es Sinn ergibt und gut bzw. lesbar aussieht. Das kann auch mal deutlich mehr oder deutlich weniger als 80 Zeichen in der umgebrochenen Zeile ergeben.

nman

Ja.

Begründung:

Wie jeder typografieinteressierte Mensch weiß, sollte allgemein bei Texten die Zeilenlänge nicht zu hoch sein, damit der Text bequem lesbar bleibt. (Gut gesetzte einspaltige Texte bleiben typischerweise unter ~70 Zeichen pro Zeile, abhängig von vielen anderen Faktoren.)
Schmale Zeilen erzwingen wenig verschachtelten Code.
Schmale Zeilen führen meistens zu vielen Zeilenumbrüchen, was wiederum die Lesbarkeit (und die Diffbarkeit) erhöht. (In Shellscripts ist es bspw. sehr angenehm nicht ewig lange Pipe-Kaskaden zu haben, sondern ein Programm pro Zeile; für sed-Aufrufe zählt ähnliches.)
Ich habe IDEs nie im Fullscreen-Modus laufen. Ich finde es äußerst lästig, wenn mein Code mich dazu zwingt, zu scrollen oder Fenster zu vergrößern.

Ich könnte einige weitere Gründe nennen, aber das Argument der besseren Lesbarkeit bei geringeren Zeilenlängen ist schon mal sehr, sehr wichtig. Die Tatsache, dass ich beim Kürzen zu langer Zeilen meistens auch feststelle, dass ich meinen Code auch hübscher machen könnte, ist ebenfalls ein Riesenpunkt.

Wenn ich Java schreiben muss, fällt mir die 80-Zeichen-Sache auch schwerer. Hängt aber natürlich stark vom Programmierstil ab, der sich als idiomatisch etabliert hat.

Artchi

Alte Zöpfe gehören abgeschnitten! 80 Zeichen sind heute unberechtigt in unserem Umfeld. Wer druckt denn bitte heute noch Listings auf einem Endlospapier mit Nadeldrucker aus? Und außerdem nutzen wir Hochsprachen, wo wir versuchen aussagekräftige Namen für Klassen, Funktionen und Variablen zu nutzen. Da reichen 80 Zeichen nicht immer aus. Und dann die Einrückungen noch dazu. Alleine wenn ich einen Namespace, Klasse und einen switch-case-Block habe, wird es sehr eng. Weil die 80 Zeichen sich nicht alleine auf den reinen Text beziehen. Ich würde es ja akzeptieren, wenn 80 Zeichen TEXT gemeint sind... damit würde man leben können. Aber die Einrückungen mit zu zählen, verfälscht doch das Argument, das kurze Zeilen besser lesbar sind.

knivil

Wer druckt denn bitte heute noch Listings auf einem Endlospapier mit Nadeldrucker aus?

In allen Argumenten fuer 80 Zeichen pro Zeile ging es nie das Drucken.

Und außerdem nutzen wir Hochsprachen, wo wir versuchen aussagekräftige Namen für Klassen, Funktionen und Variablen zu nutzen.

Haskell hat die Eigenschaft, dass dort Parameternamen eher sehr kurz sind.

foldr f z []     = z
foldr f z (x:xs) = x `f` foldr f z xs

Alte Zöpfe gehören abgeschnitten!

Naja ... Ansichtssache!

80 Zeichen sind heute unberechtigt in unserem Umfeld.

Ich lasse einige gebrachte Argumente als berechtigt gelten.

immer < 80 Z.

ich habe auch noch nie Bedarf nach längeren Zeilen gehabt, und wenn, dann war der Code immer überarbeitungsbedürftig (zu tief Verschachteltes, ungünstige Bezeichner, zu lange Parameterlisten, zuviel Code in einer Funktion ...)

this-*gt*that

Nein. In Zeiten von Widescreen HD-Monitoren halte ich das für völlig antiquiert. Außerdem druckt man ja doch eh nie Sourcecode aus. Das macht man vllt mal als Anfänger in der Uni, aber in realen Projekten mit mehr als 100k LOC druckt niemand mehr irgendwas aus.

Mein persönliches weiches Limit sind ca. 100 Spalten.

knivil

Manche scheinen nicht zu verstehen, dass andere mit mehr als ein Editorfenster (ich z.B. meist 3 oder 4) nebeneinander arbeiten und zusaetzlich Console und Browser offen haben. Ich freue mich sehr, dass das meiste jetzt auf einen Bildschirm passt.

Und: Ich bin nicht antiquiert.

this-*gt*that

knivil schrieb:

Manche scheinen nicht zu verstehen, dass andere mit mehr als ein Editorfenster (ich z.B. meist 3 oder 4) nebeneinander arbeiten und zusaetzlich Console und Browser offen haben. Ich freue mich sehr, dass das meiste jetzt auf einen Bildschirm passt.

Ich auch. Allerdings auf 2 Bildschirmen. Links Visual Studio, rechts andere Editoren, Browser etc.

Mein Monitor ist so scheiße breit.. hab das gerade mal getestet, wie das aussieht, wenn ich meinen Code willkürlich bei 80 Zeilen stoppe. Sieht einfach nur lächerlich aus, wenn ca 40% vom Bildschirm weiß ist.

Shade Of Mine

80 Zeichen sind eine willkürliche Grenze. Früher war es technisch, heute nur noch willkürlich. Wozu also daran halten?

Wenn die Zeile 82 Zeichen lang ist, dann breche ich sicher nicht um. Wenn sie 100 Zeichen lang ist wahrscheinlich auch nicht. Bei 150 vermutlich schon. Aber diese ganzen fixen Regeln beschränken mehr als sie nutzen.

Es macht viel mehr Sinn dort umzubrechen wo es für die Codezeile Sinn macht. Manchmal breche ich öfters um weil auf jeder Zeile eine essentielle Info steht:

$arr = array(
  'foo1' => 'bar',
  'foo2' => 'bar2',
  'foo3' => 'bar3',
  ...
);

zB auch bei if wenn es mehrere Bedingungen gibt.

knivil

Also braucht man schon 2 Bildschirme um nicht antiquiert zu sein? Auch arbeite ich meist an mehreren Dateien des gleichen Programms. Da machen sich 2 oder mehr Editorfenster nebeneinander recht praktisch. Da bleibt nichts weiss. Kann aber nicht jede IDE.

Es macht viel mehr Sinn dort umzubrechen wo es für die Codezeile Sinn macht.

Selbstverstaendlich. Aber es gibt bei mir recht wenige Situationen, wo es unsinnig waere, mehr als 80 Zeichen zu nutzen.

this-*gt*that

knivil schrieb:

Also braucht man schon 2 Bildschirme um nicht antiquiert zu sein?

Nein. Antiquiert ist es einfach zu denken, man MÜSSE bei 80 Zeilen umbrechen.

nman

this->that schrieb:

knivil schrieb:

Also braucht man schon 2 Bildschirme um nicht antiquiert zu sein?

Nein. Antiquiert ist es einfach zu denken, man MÜSSE bei 80 Zeilen umbrechen.

Es hat niemand behauptet, dass man das _muss_. Es wurde nur mehrfach gesagt, dass es Gründe gibt, die dafür sprechen bzw. dafür sprechen können. Unabhängig davon, wieviele Bildschirme man besitzt und wie groß die sind.

Ich lese auch keine Texte über die volle Breite meines 27-Zöllers. Auch wenn es theoretisch natürlich möglich wäre, ist es in der Praxis sehr unangenehm.

Shade Of Mine

knivil schrieb:

Es macht viel mehr Sinn dort umzubrechen wo es für die Codezeile Sinn macht.

Selbstverstaendlich. Aber es gibt bei mir recht wenige Situationen, wo es unsinnig waere, mehr als 80 Zeichen zu nutzen.

Hängt auch stark von der Sprache ab. in Python sind meine Zeilen immer sau kurz, in PHP - bis auf array definitionen ebenfalls. In C# dagegen werden die Zeilen schnell auch mal länger, da jeder Funktionname ja schon alleine mal 70 Buchstaben hat

Und ich wüsste jetzt nicht warum ich 2 Fenster gleichzeitig aufhaben sollte. Ich habe schon ein zweites fenster, dass mir den Kontext der markierten Zeile zeigt, aber darin arbeite ich ja nicht. Ansonsten springe ich per bookmarks durch die Dateien bzw. "Go To Declaration/Definition" und eben Zurück/Vorwärts.

Aber selbst 3 fenster wären nebeneinander kein Problem auf einen 16:9 monitor... Prinzipiell braucht man aber mehr Fensterplatz wenn man effektiver arbeiten will.

nman

Shade Of Mine schrieb:

Hängt auch stark von der Sprache ab.

Ack. Es gibt einige Sprachen, mit denen 80 Spalten pro Zeile sehr, sehr mühsam wären.

Und ich wüsste jetzt nicht warum ich 2 Fenster gleichzeitig aufhaben sollte. Ich habe schon ein zweites fenster, dass mir den Kontext der markierten Zeile zeigt, aber darin arbeite ich ja nicht. Ansonsten springe ich per bookmarks durch die Dateien bzw. "Go To Declaration/Definition" und eben Zurück/Vorwärts.

Um die geistigen Kontextswitches und die kurze Orientierungszeit des Herumspringens zu minimieren. Natürlich nicht immer und dauernd. Aber es gibt doch immer wieder Situationen in denen ich sehr gerne viele Fenster gleichzeitig offen habe, einfach um mich nicht ständig umorientieren zu müssen, wo ich gerade bin.

Ist auch einer der Gründe, warum ich so gerne einen Extra-Monitor im Hochformat für Doku verwende.

Dravere

Ich halte mich auch nicht fix an die 80 Zeichen pro Zeile Regel. Wieviele Zeichen es sein können, hängt schliesslich auch noch von der Schriftart und -grösse ab.

Meistens lasse ich mir eine senkrechte Linie bei 120 Zeichen anzeigen, dass ist für mich aber nur ein Indikator. Allerdings denke ich, dass 95% oder mehr von meinem Code nicht breiter als 80 Zeichen sein wird. Man will ja keine ellenlangen Zeilen schreiben und bricht ganz automatisch den Code auf.

Grüssli

berniebutt

Die 80 Zeichen pro Zeile stammen aus der Zeit der Lochkarten, die genau 80 Lochspalten hatten. Die textorientierten Bildschirme hatten zunächst auch nur Platz für 80 Zeichen. Dennoch konnte man stets mit Folgezeilen mehr schreiben und hat das getan.
Heute gilt die Lesbarkeit eines Source-Codes. Auch da beschränke ich mich auf den Editor und den problemlosen Ausdruck auf Papier.
Denke nicht so viel über Zeilenlängen nach, sondern über die Anzahl der Zeilen je Funktion. Wenn du mehrere Seiten brauchst, ist eine weitere Unterteilung in separate Module sinnvoll. Wenn du dabei auch noch das Prinzip EVA (Eingabe-Verarbeitung-Ausgabe) anwendest, hast du zugleich auch etwas für die Wartungsfreundlichkeit des Programmes gemacht.