C/C++; Tabs oder Leerzeichen; wie viele Zeichen pro Tab; Zeichen Limit pro Zeile?
Ich verwende aktuell Tabs für den Einzug, welche 4 Zeichen groß sind und begrenze mich auf 80 Zeichen pro Zeile.
Ich habe auf GitHub gesehen, das sie 8 Zeichen beim Tab verwenden, was ich als viel zu groß empfinde.
Wenn ich den Quellcode hier oder auf StackOverflow veröffentliche, ersetze ich die Tabs gegen Leerzeichen, damit es keine Formatierungsfehler gibt.
Was verwendet ihr für C und oder C++?
Ich habe schon recherchiert, aber eine richtig allgemeine Norm habe ich nicht gefunden. Hat das womöglich jemand studiert und eine Norm gelernt, an die man sich richten sollte?
6 Antworten
Wenn ich den Quellcode hier (...) veröffentliche, ersetze ich die Tabs gegen Leerzeichen, damit es keine Formatierungsfehler gibt.
Ja, das ist auch der Grund, wieso oft von Tabs abgeraten wird. Sie können in jedem Programm anders dargestellt werden. Vergleiche bspw. einmal den Tab im Notepad (Windows) mit einem Tab in bspw. Notepad++.
Zur Einrückungstiefe:
Oft variiert es zwischen 2, 4 oder 8 Leerzeichen.
Der Google Style Guide nutzt bspw. nur 2:
Use only spaces, and indent 2 spaces at a time.
We use spaces for indentation. Do not use tabs in your code. You should set your editor to emit spaces when you hit the tab key.
Ich vermute einmal, man möchte so zum einen vermeiden, bei tiefer Verschachtelung schnell an das Zeilenende zu gelangen, ab dem man umbrechen muss und vermutlich geht es ebenfalls um die Tippgeschwindigkeit.
Würdest du dich an dem (Linux) Kernel-Style orientieren (typisch für C), wäre die bevorzugte Einrückungstiefe 8 Zeichen. Man vertritt hierbei die Meinung, dass der Code so auch nach längerer Arbeitszeit noch leicht zu lesen sei.
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you’ve been looking at your screen for 20 straight hours, you’ll find it a lot easier to see how the indentation works if you have large indentations.
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program.
In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning.
Und zu guter Letzt ein Blick auf den K&R-Stil, der weit verbreitet für C/C++ ist. Hier wird eine Einrückungstiefe von 4 Leerzeichen gewählt. Wenn du dir dazu noch die C++ Core Guidelines von Stroustrup und Sutter anschaust, wirst du dieselbe Einrückungstiefe in den Code-Beispielen finden.
In IDEs wie Visual Studio, NetBeans, Eclipse, CLion oder dem QtCreator ist standardmäßig ebenso eine Tiefe von 4 Zeichen gesetzt. Ob sich die Entwickler da an selbst bevorzugte Präferenzen, das Nutzerverhalten, Studien, einen Würfel oder Vorgaben bestimmter Autoritäten/Conventions gehalten haben, kann ich allerdings nicht sagen. Wenn ich mich recht erinnere, habe ich einmal von Studien gelesen, die 2-4 Leerzeichen als optimale Tiefe belegt haben, um verständlichen Code zu schreiben.
Wenn du mich nach meiner persönlichen Meinung fragen würdest, würde ich auf 4 Leerzeichen verweisen und empfehlen, die IDE passend zu konfigurieren (wobei das auch meist schon so eingestellt ist), sodass bei Tab stattdessen Leerzeichen eingefügt werden. Nur 2 Leerzeichen halte ich für zu kurz und 8 für viel zu lang.
Zum Zeichenlimit je Zeile:
Was die Linux-Entwickler dazu sagen, lässt sich bereits oben nachlesen und nach K&R ist das Zeichenlimit ebenfalls auf 80 beschränkt.
So, wie es der Styleguide von Google angeht, finde ich es nicht schlecht. Die Entwickler setzen auf 80 Zeichen mit Ausnahmen und argumentieren dazu (pro/kontra). Hierzu diesmal nur ein Link: https://google.github.io/styleguide/cppguide.html#Line_Length
Im Übrigen helfen IDEs erneut aus, indem sie mit einer vertikalen Linie anzeigen, wann eine Zeile umbrechen sollte. Wobei die Standardwerte diesmal meines Wissens eher auseinandergehen (80-120).
Ich verwende die vertikale Linie bei Notepad++ und bei Visual Studio.
Ich bevorzuge 80 Zeichen.
Das mit den Leerzeichen ist interessant, womöglich sollte ich anfangen, 4 Leerzeichen zu verwenden, wenn es wirklich offiziell empfohlen wird.
Die Linux Styling Guide empfiehlt auch so viele Funktionen wie möglich zu verwenden.
Ja, das ist ein guter Rat, der in mehreren Ratgebern zu dem Thema stehen dürfte.
Oft wird hierbei auch mit ungefähren Zeilenzahlen argumentiert (eine Funktion sollte nicht länger als 9-13 Zeilen lang sein).
Ich empfinde solche Regelungen allerdings für viel zu pauschal und schaue lieber fallabhängig nach allgemeiner Aufteilungsregel (jede Funktion erfüllt nur einen Zweck, Teilaufgaben werden abgespalten).
Das kleine Problem mit den Leerzeichen ist, das sie meistens mehrere statt einem Byte brauchen (...)
Wie viel Leerzeichen man zur Entwicklungszeit einbringt, ist ja glücklicherweise meist nicht wichtig für die Produktivversion. Entweder schrumpfen sie bei der Kompilierung oder man setzt ein Programm ein, welches den Code vor der Ausführung explizit kürzt (s. Uglifier bei JavaScript).
Ich nutze Tabs mit 3 Zeichen breite.
Bei der Zeilenbreite strebe ich 60 Zeichen an, achte aber darauf, nicht über 70 zu kommen.
Da ich kein Freund von hoher zyklomatischer Komplexxität bin, rücke ich sowieso kaum mehr als zwei Ebenen ein.
Tabs haben den Vorteil, dass sich jeder die Breite anpassen kann, wie er lustig ist, ohne etwas am Code ändern zu müssen. Bei Leerzeichen gilt diese Freihei nicht, weshalb ich Tabs für überlegen / erstrebenswert halte.
Solange du Tabs nutzt, bleibt es dir überlassen, wie breit du sie dir einstellst. Über solche Dinge müssen sich nur Leerzeichennutzer gedanken machen. :)
Tabs mit 3 Zeichen
Zeilenbreite strebe ich 60 Zeichen an, achte aber darauf, nicht über 70 zu kommen.
Das ist mal etwas anderes, exotisches von dem ich noch nie gehört habe ^^
Auf jeden Fall ist dein Code dann sehr kompakt und mit 70 Zeichen wirklich schmal.
Tabs haben den Vorteil, dass sich jeder die Breite anpassen kann, wie er lustig ist, ohne etwas am Code ändern zu müssen. Bei Leerzeichen gilt diese Freihei nicht, weshalb ich Tabs für überlegen / erstrebenswert halte.
Es geht bei den Leerzeichen auch darum, das es kompatibel bleibt und das die Darstellung überall gleich ist.
Bei Python z. B. könnte es problematisch werden, sobald Leer und Tabs gemischt werden.
Mann könnte aber auch argumentieren, das Tabs der Datei weniger Speicher und damit auch schnellere Verarbeitung ermöglichen etc.
Wenn ich Code irgendwo posten will, nutze ich vorher das "expand" Kommando meiner Shell.
Und 3 Zeichen breite Tabs haben sich irgendwie so heraus kristallisiert ... weiß selber nicht genau wann und wieso.
2 Zeichen sind mir zu schmal, und 4 zu breit. Und irgendwo anders habe ich schon mal bei einem sehr großen Projekt gelesen, dass 3 Tabs in den Guidelines bzw. im Styleguide stehen.
Kommt also hin und wieder tatsächlich vor. :)
Außer mit den kurzen Zeilen ... da stimme ich dir zu, das ist etwas exotisch und mein persönlicher Fetisch. :)
8 Chars sind für einen TAB die klassische Distanz, da aber dynamisch änderbar kann das eben jeder nach Präferenz einstellen.
Die 80 Zeichen kamen daher, daß früher (tm) mit monospaced Font auf VGA genau 80 Zeichen darstellbar sind, in Zeiten von 16:9 Display ist das ein wenig absurd. (VGA Font 8x16, bei 640x480 ... )
Grundlegend:
Im Idealfall sollte eine Zeile komplett erfassbar sein. Da heute x-res < 1280 kaum noch vorkommen und wir von 10pt ausgehen, dann wären das 128 Zeichen.
Auch in HTML sind 4 Leerzeichen als Tab gängig. Was die maximale Zeilenlänge betrifft kann ich mir nicht vorstellen, dass bei 80 Schluss ist.
Was die maximale Zeilenlänge betrifft kann ich mir nicht vorstellen, dass bei 80 Schluss ist.
Sich irgendein Limit zu setzen ist aber wichtig!
Dann kann man beim Texteditor den Zoom und die Fenstergröße so anpassen, dass man nichts mehr ändern muss.
Das macht es mir viel einfacher Quellcode zu schreiben.
Interessante Frage. Habe kurz mal auf Wikipedia nachgelesen. Habe aber nichts von einem genormten Abstand gefunden.
Word setzt in z.B. standartmäßig auf 1.25
Auf Github folgendes: https://stackoverflow.com/questions/809859/optimal-tab-size-for-code-readability
80 Zeichen im Code-Editor, oder 80 Zeichen in der Ausgabe wenn du eine Consolenanwendung hast?
Linux Kernel Styling Guide hatte ich schon mal gelesen, ich finde, sie ist ziemlich lustig geschrieben.
Das Argument mit 8 Zeichen Pro Zeile mag auf C Code tatsächlich zutreffen.
Die Linux Styling Guide empfiehlt auch so viele Funktionen wie möglich zu verwenden. Ein Rat, den ich mir in jeder Programmiersprache mittlerweile angeeignet habe. Mehr als 3 Einzüge sind oft ein Anzeichen dafür, das der Code einfach zu wenig Funktionen hat.
Früher vertrat ich die Annahme, dass man nur Funktionen erstellen sollte, sobald ein Code mindestens 2x gebraucht wird. Mittlerweile habe ich begriffen, dass Funktionen noch eine Aufgabe haben, die der Gliederung. Viele Funktionen zu verwenden gibt den Codeabschnitten mit dem Funktionsnamen eine "Überschrift", welche das Verständnis eines Lesers später bei Weitem erleichtert.
___
Das kleine Problem mit den Leerzeichen ist, das sie meistens mehrere statt einem Byte brauchen und das macht den Code, wenn man so will, weniger elegant. Dann könnte ein pedantischer Perfektionist auch noch argumentieren, dass Tabs schneller verarbeitet werden können als mehrere Leerzeichen.
Aber im Endeffekt kann das selbstverständlich jeder selber entscheiden.