Übersicht Groß/Kleinschreibung etc für gleichmäßigen Stil

corado

Gibt es im netz oder hier, irgendwo eine Übersicht empfohlener Regeln wie was geschrieben werden sollte?
Also Makros immer groß
Variablen den ersten Buchstaben groß
Konstanten z.B. die ersten beiden Zeichen etc pp?
Ich kenne es leider aus meiner Pascal Zeit so, daß es jeder und jedes buch anders macht, daher habe ich mir bis heute keinen einheitlichen Stil angeeignet...

Jockelx

@corado sagte in Übersicht Groß/Kleinschreibung etc für gleichmäßigen Stil:

Gibt es im netz oder hier, irgendwo eine Übersicht empfohlener Regeln wie was geschrieben werden sollte?

Hallo, nein, gibt es nicht - zumindest keine seriöse.
Du kannst dir mal die Vorschläge in den core-guidlines anschauen. Da wird aber dann auch zurecht darauf hingewiesen, dass vor allem Konsistenz wichtig ist.

wob

Halte dich an den Code, mit dem du zu tun hast.

Persönliche Meinung:

Makros: möglichst gar nicht verwenden, wenn doch, dann ALL_CAPS
Klassennamen: PascalCase.
Variablen, Funktionen: snake_case (früher war ich absoluter camelCase-Fan, finde aber inzwischen, dass das manchmal zu Problemen oder schlechter lesbaren Namen führt)
Einrückung: 4 Spaces (nicht 2 oder 3), dafür lieber 95 Zeichen pro Zeile (statt nur 80)

Am wichtigsten aber: Konsistenz innerhalb einer Datei.

Finnegan

@wob sagte in Übersicht Groß/Kleinschreibung etc für gleichmäßigen Stil:

Halte dich an den Code, mit dem du zu tun hast.

Ganz wichtig. Erstmal den Stil des Projekts beibehalten, an dem man arbeitet. Bei eigenen Projekten oder wenn an in der Position ist, einen Stil definieren zu können, greifen dann die persönlichen Präferenzen, die aber IMHO auch immer wohlbegründet sein sollten.

Klassennamen: PascalCase.

Variablen, Funktionen: snake_case (früher war ich absoluter camelCase-Fan, finde aber inzwischen, dass das manchmal zu Problemen oder schlechter lesbaren Namen führt)

Interessant, das deckt ich genau mit meinem bevorzugten Stil. Klassen in PascalCase und dann Variablen+Funktionen im Stil der Standardbibliothek sieht zwar erstmal etwas komisch aus, hat aber den Vorteil, dass man die Kategorien der Identifier auch ohne Syntax-Highlighting visuell relativ schnell auseinanderhalten kann. Geht zumindest mir so.

Einrückung: 4 Spaces (nicht 2 oder 3), dafür lieber 95 Zeichen pro Zeile (statt nur 80)

Früher habe ich sogar 120 Zeichen bevorzugt - "die Zeiten des 80x25-Textmodus sind lange vorbei" dachte ich mir. Mittlerweile bin ich aber tatsächlich wieder bei 80 Zeichen gelandet. Überzeugt haben mich Untersuchungen, die ungefähr diese Zeilenbreite als "Sweet Spot" für angenehmes Lesen von allgemeinen Texten ausgemacht haben. Wird die Zeile zu lang, muss der Blick horizontal zu weit wandern und man bekommt schonmal Probleme, die nächste Zeile zu "treffen". Manchal landet man dann in der übernächsten. 95 Zeichen it aber genau so gut. Hauptsache halt nicht zu lang.

Als hilfreich für gute Lesbareit, wenn man eine Zeilenbreite einhalten will, finde ich auch folgende Regel: Parameterlisten sind etweder horizontal oder vertikal ausgerichtet. Niemals gemischt. So wandert der Blick beim Lesen immer von links nach rechts oder von oben nach unten:

template <typename T1, typename T2, typename T3> 
void funktion1(T1 parameter1, T2 parameter2, T3 parameter3);

template <
    typename T1,
    typename T2,
    typename T3,
    typename T4,
    typename T5,
    typename T6
> 
void funktion2(
    T1 parameter1,
    T2 parameter2,
    T3 parameter3,
    T4 parameter4,
    T5 parameter5,
    T6 parameter6
);

Es hat eine Weile gedauert, aber mittlerweile unterstützt auch clang-format diesen Stil. Damit stehe ich also nicht so ganz allein auf weiter Flur wie mit den Trailing Return Types

Alles natürlich nur persönliche Präferenzen, daher gilt:

Am wichtigsten aber: Konsistenz innerhalb einer Datei.

Auf jeden Fall

Zusatz: Man muss allerdings auch erwähnen, dass es wohl kaum eine andere Sprache gibt, in der es so viele unterschiedliche Code-Stile gibt, wie in C++. Mit ein bisschen Chaos muss man also immer leben. Spätestens wenn man 2 verschiedene Bibliotheken mit unterschiedlichen Stilen nutzt, die an Schnittstellen in das eigene Projekt "hineindiffundieren" hat man keine andere Wahl.

wob

@Finnegan sagte in Übersicht Groß/Kleinschreibung etc für gleichmäßigen Stil:

Früher habe ich sogar 120 Zeichen bevorzugt - "die Zeiten des 80x25-Textmodus sind lange vorbei" dachte ich mir. Mittlerweile bin ich aber tatsächlich wieder bei 80 Zeichen gelandet.

Wir haben oft eher lange Variablennamen. Wenn man dann in einem if einer Fkt einer Klasse ist, sind durch die Einrückungen schon recht viele Zeichen verbraucht. Oft möchte ich die Formel aber trotzdem in einer Zeile lesen können und nicht vor einem Plus oder Mal umbrechen.

Ich habe festgestellt, dass in Code, der nicht so projektspezifisch ist, lange Variablennamen i.d.R. nicht auftreten und ich dort auch mit weniger als 95 leben könnte. Ich enforce 120 Zeichen als Limit in Jenkins, lasse by default aber bei 95 umbrechen (d.h. man muss Formatierung explizit ausstellen, wenn man mehr als 95 will).

Es ist allerdings so, dass ich kaum noch neuen C++-Code schreibe, sondern überwiegend Python nutze. Und da hat black (Standard-Formatierungstool fast ohne Steuerparameter) als Default 88 Zeichen pro Zeile. Die 7 Zeichen mehr auf 95 (machen wir auch in Python) bringen echt sehr viel. Black sieht das mit dem Umbruch von Funktionsargumenten übrigens genauso wie du. Entweder alles in einer Zeile oder eine Zeile pro Argument.

Edit: Zitat von Black (https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html):

You probably noticed the peculiar default line length. Black defaults to 88 characters per line, which happens to be 10% over 80. This number was found to produce significantly shorter files than sticking with 80 (the most popular), or even 79 (used by the standard library). In general, 90-ish seems like the wise choice.

Leon0402

Ich bin auch Verfechter von vielen Zeichen pro Zeile. Glaube ich habe bei clang-format 120 Zeichen pro Zeile eingestellt. Die 80 halte ich nicht für zeitgemäß.

Außerdem bieten gängige Editoren wie VS Code an, Zeilen umzubrechnen bei einer fixen anzahl oder gemessen am Viewort. Also die Zeilen werden nur für einen selbst umgebrochen, im Editor erstreckt sich dann quasi eine nummerierte Zeile über mehrere Zeilen. In Git etc. bleibt es eine Zeile.

Meine Standardeinstellung ist also 120 Zeichen pro Zeile & automatisches umbrechnen nur für mich gemessen am Viewport. Dann gibt es auch keine Probleme, wenn ich mal 2 Fenster nebeneinander habe etc.

Wenn man 80 Zeichen pro Zeile hat, tendiert man dazu Dinge zu kürzen aus meiner Erfahrung. In C++ werden Bezeichner vlt. kürzer. In Python lässt man vlt. Typing wegs oder so. Das halte ich für kontraproduktiv.

wob

@Leon0402 sagte in Übersicht Groß/Kleinschreibung etc für gleichmäßigen Stil:

Wenn man 80 Zeichen pro Zeile hat, tendiert man dazu Dinge zu kürzen aus meiner Erfahrung.

Ja, sehe ich auch so, weil es auch bei Regeln wie "mehr als 80 sind in Ausnahmen erlaubt" in einer Firma immer irgendwen gibt, der sich dann doch auf irgendeine feste Regel beruft (und mit ungefähr 90-ish nicht klarkommt) und ggf dann ständig reine Formatierungscommits macht. Deswegen enforcen wir die Formatierung auch mit einem Formatierungstool (clang-format in C++ bzw black und isort in Python). Dann gibt es schonmal keinen nutzlosen Streit mehr, wie etwas nun besser aussieht. Black hat zudem noch den Vorteil, dass man außer der Zeilenlänge nichts konfigurieren kann, d.h. es gibt erst gar keine Diskussion, welche Einstellungen wir haben wollen.

In C++ werden Bezeichner vlt. kürzer. In Python lässt man vlt. Typing wegs oder so. Das halte ich für kontraproduktiv.

Nö, weggelassen wird nichts. Neuer Code muss Type-Annotationen haben, sonst lassen wir ihn nicht durchs Review. Mit der Bezeichnerlänge: das sehe ich genauso.

Wenn 120 Zeichen erlaubt sind, führt das meiner Meinung nach zu viel zu tief verschachteltem Code. Man ist nicht mehr "gezwungen", Dinge in eine Funktion auszulagern. Hat man weniger Platz, macht man vielleicht eine neue, gut benannte bool-Variable aus 2 oder 3 anderen, die man dann in den Zeilen danach per if abfragt, anstelle direkt im if zu kombinieren, wenn man so viel Platz nutzen darf. Daher: zu viel Platz ist nicht gut (zu wenig auch nicht). Ich bin daher Fan von 90-ish.

@corado In dem oben von mir verlinkten Video über 90-ish Zeichen geht es zunächst um Formatierung. Dann läuft aber ein Gorilla durchs Bild. Die Lektion ist: es gibt häufig wesentlich wichtigere Dinge, nämlich Code so zu schreiben, wie es idiomatisch für eine Sprache ist. Was hilft dir die beste Formatierung, wenn du z.B. C-Style Code in C++ verwendest. Der Code wird dann durch die Formatierung nicht besser, aber ggf. fällt stärker auf, was schlecht ist.

Leon0402

@wob sagte in Übersicht Groß/Kleinschreibung etc für gleichmäßigen Stil:

Daher: zu viel Platz ist nicht gut (zu wenig auch nicht). Ich bin daher Fan von 90-ish.

Vermutlich alles eine Frage des Geschmacks am Ende

Ein Gegenargument gegen zu wenig Zeichen pro Zeile will ich aber noch geben: Die Annahme, dass Entwickler <hier schlechten Code Stil einfügen> weglassen würden, wenn man nicht zu viel Spielraum gibt, halte ich für Spekulation. Besser finde ich dagegen Reviews zu machen und bei Bedarf Guidelines aufzustellen mit Dos und Don'ts. Seine Hoffnung darauf zu setzen, dass Leute schon guten Code automatisch schreiben, wenn man die Zeilenlänge runtersetzt, finde ich etwas komisch.

Dein Beispiel oben wäre so ein Fall. Wenn jemand meint Dinge nicht in Funktionen auszulagern oder ultrakomplexe if statements zu formulieren, dann liegt das Problem doch wirklich beim Entwickler. Dieser sollte lernen z.B. durch ein Code Review, dass sein Code so nicht so toll lesbar ist.

Umgekehrt sehe ich aber ein zu kleines Zeilenlimit oft als Motivation aus einem guten Programmierer einen schlechten zu machen. Mein Beispiel mit den Typing bei Pythons kam daher, dasss diese enorm viel Platz brauchen, allerdings grundsätzlich optional sind. Bei einem geringen Zeilenlimit kommen dann Entwickler eben gerne auf die Idee, die wegzulassen. Insbesondere dann, wenn es grade so nicht in eine Zeile passt. Ist natürlich gut, dass ihr das trotzdem unterbindet im Code Review

Ansonsten muss ich ganz ehrlich sagen, dass mir vieles mittlerweile relativ schnuppe ist. Solange das Projekt ne clang format Datei o.ä. hat, passe ich mich an. Leider funktioniert das aber natürlich nicht bei allen Dingen, die man so typischerweise in einem Coding Style Guide findet.
Vermissen tue ich z.B. so sachen wie camelCase, snake_case Konventionen etc.
Allerdings müsste dafür clang_format vermutlich sehr viel intelligenter sein, um solche Sachen konsistent zu halten.

Edit: Wo ich bisher noch nicht so "entspannt" bin sind so ein paar komplexere Formatting / Style Sachen. Beispielweise nutze ich super gerne early returns für Fehlerfälle etc. Oder Exceptions statt Fehlercodes. Da quäle ich mich immer etwas, wenn ich mich da anpassen muss

wob

@Leon0402 sagte in Übersicht Groß/Kleinschreibung etc für gleichmäßigen Stil:

Vermissen tue ich z.B. so sachen wie camelCase, snake_case Konventionen etc.

clang-tidy kann das.
Siehe https://clang.llvm.org/extra/clang-tidy/checks/readability/identifier-naming.html

$ cat x.cpp 
class x {};
int main(){}

$ clang-tidy-14 -checks='-*,readability-identifier-naming' -config="{CheckOptions: [{key: readability-identifier-naming.ClassCase, value: CamelCase}]}" x.cpp 
Error while trying to load a compilation database:
Could not auto-detect compilation database for file "x.cpp"
No compilation database found in /tmp or any parent directory
fixed-compilation-database: Error while opening fixed database: No such file or directory
json-compilation-database: Error while opening JSON database: No such file or directory
Running without flags.
1 warning generated.
/tmp/x.cpp:1:7: warning: invalid case style for class 'x' [readability-identifier-naming]
class x {};
      ^
      X

In Python geht das z.B. mit pylint.

Leon0402

@wob Okay das ist cool. Das wusste ich noch nicht Da ich clang-tidy schon nutze, sollte ich das mal schnell einbauen.

Allerdings gibt es nur Warnings, oder? Das schöne an clang-format ist ja, dass es die Sachen fixt. Ich kann also so programmieren wie ich will und es kenne und clang-format fixt es. Und wenn man irgendwann dinge anders formattiert haben will, geht das auch.

Aber clang-tidy zu haben, um Warnings zu geben, ist zumindest besser als nix zu haben.

*john 0

Es werden keine Lochkarten und 80 Zeichen Terminals mehr verwendet, daher ist die Beschränkung auf 80 Zeichen sehr aus der Zeit gefallen. Wer das Lochkarten Erlebnis in Ansätzen an einem modernen Computer erleben will, sollte Fortran mit dem veraltetem fixed form ausprobieren. (Sehr sehenswert ist übrigens dieses Video). Da sind 5 Spalten für die Zeilennummer reserviert, eine Spalte für das Umbruch-/Kommentarzeichen, dann kommen 66 Spalten für den eigentlichen Code, und die letzten 8 Spalten sind für Anmerkungen bzw. Beschriftung der Lochkarten gedacht. Wenn die Karten maschinell geschrieben wurden, wurde diese letzten 8 Spalte auf die Karte gedruckt, und die ersten 72 Spalten gelocht. Hat man von Hand gelocht (es gab früher so eine Art Schreibmaschine für Lochkarten), musste man die Karten selbst beschriften.

Leider kenne ich Personen, die noch immer an diesem altem Format festhalten. Die neue free form erlaubt 132 Zeichen pro Zeile und der ganze Lochkarten Nonsense gibt es nicht mehr. Die fixed form kommt gleich nach Perl Sourcecode.

Was das Formatieren des Codes allgemein betrifft, bleibt da konsistent und bleibt in einem Projekt bei einem Stil. Tools können dabei helfen.

Finnegan

@john-0 sagte in Übersicht Groß/Kleinschreibung etc für gleichmäßigen Stil:

Es werden keine Lochkarten und 80 Zeichen Terminals mehr verwendet, daher ist die Beschränkung auf 80 Zeichen sehr aus der Zeit gefallen.

Das zeitlose Argument ist auch gute Lesbarkeit und nicht irgendwelche technischen Einschränkungen. Es gibt schon einen Grund, weshalb klasische Papierzeitungen in Spalten organisiert waren anstatt die Zeilen über die gesamte Breite des Blatts zu führen. Es müssen nicht unbedigt 80 Zeichen sein, aber ungefähr in dieser Größenordnung liegt die Zeilenbreite, welche die meisten Menschen als angenehm empfinden.

SeppJ

Da besteht aber ein großer Unterschied zwischen dem Lesen eines langen Fließtexts und wie man Programmcode liest.

Zeitungstext ist ein einziger, langer Fluss und die Aufteilung in mehrere Zeilen ist nur eine technische Notwendigkeit. Daher will man die Zeilen möglichst nicht zu sehr optisch trennen und wählt daher kürzere Zeilen, damit das Auge nicht so sehr springen muss.

Programmtexte haben genau die gegenteilige Eigenschaft. Jede Zeile soll eine einzige, geschlossene, logische Einheit für sich sein. Die Aufteilung in Zeilen dient der optischen Trennung dieser Einheiten. Daher ist es besser, wenn eine logische Einheit auch möglichst komplett in eine Zeile passt. Wenn man doch gezwungen ist aus technischen Gründen (Monitorbreite oder Codingstandards) würde man auch niemals die Codezeile einfach dort umbrechen wo man gerade ist (wie man es bei einem Zeitungstext machen würde) sondern versucht dann eine Aufteilung in kleinere logische Einheiten.

Finnegan

@SeppJ sagte in Übersicht Groß/Kleinschreibung etc für gleichmäßigen Stil:

Programmtexte haben genau die gegenteilige Eigenschaft. Jede Zeile soll eine einzige, geschlossene, logische Einheit für sich sein. Die Aufteilung in Zeilen dient der optischen Trennung dieser Einheiten.

Ich sehe eher Einrückungblöcke als diese Einheiten und erachte es als nicht unbedingt notwendig, sich dabei auf Zeilen zu beschränken. Das ist denek ich nicht so in Stein gemeißelt, wie du das hier darstellst ("Jede Zeile soll ..."). Siehe oben mit horizotalem oder vertikalem Layout von Parametern. Das ist insofern flexibler, als dass damit diese Einheiten beliebig lang werden können. Ich denke zu lange Zeilen, für die man selbst auf einem breiten Monitor scrollen muss, sind wahrscheinich auch nicht in deinem Sinne.

Auch ist es so, dass ich zumindest bei eier Arbeitsweise oft verchiedene Codestellen nebeeinander betrachte. Nicht zu lange Zeilen finde ich da wesenetlich angenehmer zu handhaben.

Daher ist es besser, wenn eine logische Einheit auch möglichst komplett in eine Zeile passt.

Ja, das ist nachvollziehbar, wenn man eben Zeilen als solche Einheiten betrachtet. Allerdings ist es auch eine Frage, wie weit man die Einheiten herunterbricht. Ist eine komplette Funktionssignatur eine Einheit eventuell sogar noch mit Template-Parameterlisten (auch schon gesehen), oder sind Templates, Funtionsname (+ öffnende Klammer) und jeder einzelne komma-separierte Parameter eine eigene Einheit?

Generell stimme ich da zu mit den "Zeileneinheiten", vor allem dass auch in einer Zeile nicht zu viel passieren sollte. Lieber Anweisugen aufsplitten als Zuweisung, Vergleich, Berechnung und Inkrement in die selbe Zeile zu stopfen. In de Sinne sehe ich Zeilen eben auch als optische Trennung funktionaler Einheiten. Ich sehe das aber nicht so strikt, dass es die für mich schlechtere Handhabbarkeit besoners langer Zeilen überwiegen würde.

Wenn man doch gezwungen ist aus technischen Gründen (Monitorbreite oder Codingstandards) würde man auch niemals die Codezeile einfach dort umbrechen wo man gerade ist (wie man es bei einem Zeitungstext machen würde) sondern versucht dann eine Aufteilung in kleinere logische Einheiten.

Zu "Monitor" sei noch angemerkt, dass es auch sehr unterschiedliche Anzeigegeräte und Bildschirmauflösungen gibt. Was für den einen gut lesbar erscheint, kann bei jemand anderem lästiges Scrollen erfordern. Sei es, weil jemand ein Code-Review auf de Smartphone macht, oder eben mit einem Split-Layout. Ich sage ja nicht, dass es unbedingt 80 Zeichen sein müssen, aber beliebig lang (kenne solchen Code) empfinde ich eher als störend.

Was den "Umbruch" angeht - auch für Programmierprachen gibt es sinnvolle Trennungsregeln. Natürlich nicht silbenbasiert wie bei natürlichen Sprachen, sondern eher Token- bzw. "Einheiten"-basiert (wie immer man diese definiert). Ich brauche sicher nicht auf die verschiedenen Umbruchstrategien zu verweisen, wie sie z.B. clang-format anbietet. Das ist wenn ich dich richtig verstehe auch das, was du hier sagen willst. Ich dachte es wäre klar, dass ich hier nicht wortwörtlich den selben Umbruch wie in Zeitugsartikeln meinte. Das macht ohnehin der automatische Umbruch des Editors. Ich meine selbstverständlich einen an der Codestruktur orientieren Umbruch bei dem wir uns hoffentlich einig sind, dass ein solcher lesbarer ist als ein automatischer.

SeppJ

@Finnegan sagte in Übersicht Groß/Kleinschreibung etc für gleichmäßigen Stil:

Programmtexte haben genau die gegenteilige Eigenschaft. Jede Zeile soll eine einzige, geschlossene, logische Einheit für sich sein. Die Aufteilung in Zeilen dient der optischen Trennung dieser Einheiten.

Ich sehe eher Einrückungblöcke als diese Einheiten und erachte es als nicht unbedingt notwendig, sich dabei auf Zeilen zu beschränken. Das ist denek ich nicht so in Stein gemeißelt, wie du das hier darstellst ("Jede Zeile soll ..."). Siehe oben mit horizotalem oder vertikalem Layout von Parametern. Das ist insofern flexibler, als dass damit diese Einheiten beliebig lang werden können. Ich denke zu lange Zeilen, für die man selbst auf einem breiten Monitor scrollen muss, sind wahrscheinich auch nicht in deinem Sinne.

Häh? Das ist doch genau was ich sage? Du hast mich komplett missverstanden (wollen?). Einheit erster Stufe: Funktion oder Block. Praktisch immer zu lang (ogal ob "zu lang" via 80 Zeichen oder über Monitorgröße definiert), außer vielleicht bei trivialen Gettern/Settern (die man dann ja auch oft einzeilig schreibt). Also Aufteilung in mehrere Zeilen, eine davon ist die Funktionssignatur. Passt meistens gut lesbar an ein Stück, aber wenn nicht, teilt man sie eben an der nächsten sinnvollen Untereinheit, nämlich den Parametern. Und wenn die nicht passen, naja dann hat man einerseits ein Designproblem, aber wenn das hypothetisch irgendein super-langes Templatemonstrum ist, würde man das ja dann auch in seinen einzelnen Parameter pro Zeile schreiben.

Das ist jetzt keine tiefgehende Erkenntnis, sondern etwas was jeder wie selbstverständlich macht. Aber das ist, wieso man Zeitungstextsatzweisheiten eben nicht auf Code übertragen kann. Zeitungstext ist eine lange Folge von Worten, höchstens durch Sätze und Untersätze strukturiert (und das eher schwach). Code ist hingegen eine Liste von Ausdrücken, die wiederum rekursiv aus Unterausdrücken bestehen. Daher kann und tut man ihn auch listenartig aufschreiben.

Zeitung:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, 
sed do eiusmod tempor incididunt ut labore et dolore ma-
gna aliqua. Ut enim ad minim veniam, quis nostrud exer-
citation ullamco laboris nisi ut aliquip ex ea commodo 
consequat. Duis aute irure dolor in reprehenderit in volup-
tate velit esse cillum dolore eu fugiat nulla pariatur. Ex-
cepteur sint occaecat cupidatat non proident, sunt in cul-
pa qui officia deserunt mollit anim id est laborum

Code wie Zeitung geschrieben:

using namespace std; int main() {int intNum = 0; cin >> 
intNum;	while (intNum != 42) {cout << intNum << "\
 \n"; cin >> intNum;} return 0;}

Absurd. (Man beachte auch das C++ "Silbentrennzeichen" \ in Zeile 2)

Zu "Monitor" sei noch angemerkt, dass es auch sehr unterschiedliche Anzeigegeräte und Bildschirmauflösungen gibt.

Ja, man könnte meinen, dass das der Grund ist, warum Codingstandards meistens eine Zeilenbreite vorgeben…

Bloß stammt 80 eben aus einer Zeit der 11" großen 4:3 Monitore mit 320p Auflösung. Da kann man schon mal darüber diskutieren, ob das noch zeitgemäß ist. Wir fahren bei uns sehr gut mit 120 Zeichen, da ist selbst mit großer Schrift noch reichlich Platz an den Seiten für andere Teile der Entwicklungsumgebung. Und es ist auch nicht so absurd lang, dass der größte Teil des Bildschirms leer bliebe, bloß um eine einzige lange Zeile in einem Meer von vielen kurzen haben zu können.

hustbaer

Wir verwenden aktuell 140.

Der wichtigste Grund für mich gegen zu kleine max. Länge ist dass es dazu verleitet kurze Bezeichner zu verwenden. Was es nach meiner Erfahrung viel Mühsamer macht den Code zu lesen/navigieren. Für Code an dem man gerade aktiv arbeitet bzw. mit dem man sich gerade intensiv beschäftigt, ist es ziemlich egal. Aber in grösseren, bestehenden Projekten beschäftigt man sich eigentlich nur wirklich lange mit einem Thema wenn man grössere neue Features implementiert oder grössere bestehende Features refactored. Was normalerweise nicht so oft vorkommt. Die meiste Zeit arbeitet man mit Code von dem man ungefährt weiss was er tut, aber die Details nie kannte oder schon wieder vergessen hat. Und dann sind kurze Bezeichner halt kacke.

Das für mich beste Argument für eine kleine max. Länge ist dass man side-by-side Diffs ohne Wrapping oder Scrollen auf den Schirm bekommt. Wenn man das möchte, sollte man sich vermutlich auf 100~110 Zeichen beschränken. Weniger als 100 macht mMn. kaum Sinn. Voraussetzung ist dass man 24" Monitore oder grösser verwendet. Mit Notebooks (ohne externen Monitor) programmieren ist zwar aktuell irgendwie "in", aber mMn. einigermassen beknackt. Zumindest im professionellen Umfeld sollte man sich Arbeitsplätze mit ordentlichen Monitoren leisten können.

*john 0

@Finnegan sagte in Übersicht Groß/Kleinschreibung etc für gleichmäßigen Stil:

Das zeitlose Argument ist auch gute Lesbarkeit und nicht irgendwelche technischen Einschränkungen.

Die technischen Einschränkungen sind eine historische Tatsache, und haben früher die Lesbarkeit erheblich eingeschränkt. Ich glaube Du solltest Dir alten Fortran Code anschauen, wie dieser formatiert und organisiert wurde. Es war einfach nur grausig.

Gerade weil man die Lesbarkeit erhöhen will, ist es nicht sinnvoll die 80 Zeichen Beschränkung beizubehalten. Mittlerweile rückt man Blöcke ein, so dass effektiv weniger Platz zu Verfügung steht, wenn man sich auf 80 Zeichen beschränkt. Wenn man effektiv 80 Zeichen in einer Zeile als Lesbarkeitsgrenze ansetzt, und einen Funktionsrumpf plus eine vierfach Schleife annimmt, dann hat man mit einer Einrückungstiefe von 4 schon 20 Zeichen in der Zeile verloren. Wer 8 als Einrückungstiefe nutzt verliert sogar die halbe Zeile. Was spricht dagegen einfach den Funktionsblock um die Einrückungstiefe versetzt 80 Zeichen breit zu schreiben?

Dann existiert noch das Problem von mathematischen Formeln, die man nicht so setzen kann wie man normalen Text setzt. Das Problem überträgt sich auf Programmcode ganz analog. Wenn man längere Formel hat, dann expandieren diese zu recht langen Programmzeilen. Dabei sprechende Namen (sprich lange Namen für die Variablen) zu verwenden, reduziert die Lesbarkeit erheblich, und die Zeilen umzubrechen verbessert die Lesbarkeit des Codes nicht unbedingt, so dass dies sehr behutsam getan werden muss. Teile der Formel als Funktion auszulagern kann Probleme mit dem Optimizer ergeben, was dann die Laufzeit verlängert. Das ist dann meist ein sehr wichtiger Grund es sein zu lassen.

Es gibt schon einen Grund, weshalb klasische Papierzeitungen in Spalten organisiert waren anstatt die Zeilen über die gesamte Breite des Blatts zu führen. Es müssen nicht unbedigt 80 Zeichen sein, aber ungefähr in dieser Größenordnung liegt die Zeilenbreite, welche die meisten Menschen als angenehm empfinden.

Es kommt wieder immer auf den Kontext an. Ich halte Dogmatismus in die eine oder andere Richtung in der Sache für nicht hilfreich.