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



  • Haltet ihr die 80 Zeichen Grenze ein, die euch einen sicheren druckbaren Bereich garantiert oder schreibt ihr bei euren den Zeilen über die 80 Zeichen Linie hinaus?

    Und falls nein, gibt es Sonderfälle, bei denen ihr das doch macht?
    Z.b. andere Programmiersprache?



  • Ja.



  • Ja.



  • Ich habe inzwischen 120 oder 160 Zeichen als Grenze, darüber schreibe ich dann aber auch nicht hinaus. Ich finde 80 Zeichen sind auf den heutigen Bildschirmen schon etwas zu wenig.

    MfG SideWinder



  • Die wo jetzt Ja geantwortet haben, könntet ihr auch einen Grund nennen warum ihr das so macht?

    Ich sehe das nämlich auch wie SideWinder, die Bildschirme sind heute wirklich superbreit und zum Drucken kann man ja ne kleinere Schrift nehmen.
    Abgesehen davon, daß ich meinen Quellcode sowieso nie ausdrucke.



  • Programmierstil schrieb:

    Die wo jetzt Ja geantwortet haben, könntet ihr auch einen Grund nennen warum ihr das so macht?

    So viel senkrechte Übersicht wie früher brauche ich nicht mehr. Waagerecht reichen meistens 80. Rechenausdrücke will ich eh logisch untergliedern und komme unter 80. Ist die Zeile so langweilig, daß es völlig reicht, den Anfang zu lesen, gehe ich auch mal über 80, würde auch über 1000 gehen. Ich benutze die wahnsinnig vielen Pixels eher dazu, um die Schriftart größer zu machen.



  • Programmierstil schrieb:

    Die wo jetzt Ja geantwortet haben, könntet ihr auch einen Grund nennen warum ihr das so macht?

    Das Terminal ist zu Ende ... Ok, ernsthaft: Ich habe mehrere Terminals auf meinem Desktop, arbeite mit mehreren Dateien, ... Der Bildschirmplatz wird einfach nur durch mehr Editorfenster + Browser + Console zum Kompilieren ausgefuellt. Auch brauche ich nicht mehr als 80 Zeichen pro Zeile. .. oO ich bin immer noch wach.



  • 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ß.



  • 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>
    


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



  • 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>
    

    👍
    😃



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



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



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



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



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



  • 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. 🙂


Log in to reply