On Thursday 16 August 2001 20:45, Matthias Petermann wrote:
In meinem Lernbuch steht u.A. dass C keine Vorschriften in Punkto Design von Quelltexten macht; entsprechend rar sind daher auch die Beschreibungen dazu :( Eine interessante Datei habe ich in den Kernel-Quellen gefunden (linux/Documention/CodingStyle), in der u.A. das richtige Setzen von Klammern und Einrückungen bei for,if,etc...-Konstrukten ge- zeigt wird. Gibt es zu diesem Thema irgendwo noch Genaueres zu lesen bzw. kann mir jemand ein Buch empfehlen?
Es gibt da noch die GNU-CodingStyles(*), die sich sehr stark am alten K&R-C orientieren und in den Standardwerken zu C (u.a. die Bücher von K&R) sind wohl auch recht häufig solche Sachen drin. Letztendlich muss der Programmierer selbst entscheiden, welcher Stil am besten zu ihm passt. Eines sollte Dir dabei aber immer klar sein: der Projektleiter entscheidet - sprich: wenn Du in ein Projekt reinkommst versuch' als erstes rauszufinden welcher Stil verwendet wird. Nur eines ist schlimmer als schlecht formatierter Code: inkonsistent formatierter Code.
(*) irgendwo auf http://www.gnu.org
Das gemeine an dieser Sache ist, dass kein Stil per se besser ist als irgendein anderer - jeder hat seine Vor- und Nachteile.
Ich persönlich fahre mit dem Linux-Style immernoch am besten. Aber man kann da durchaus anderer Meinung sein (unter Windows z.B. sind 80 Zeichen _eindeutig_ zu wenig und ein Tab als Einrückung _eindeutig_ zu viel, da die Funktionsnamen viel zu lang sind).
Mal einige Beispiele: a) Einrückung == Tab == 8Spaces Vorteile: sehr übersichtlicher Code; einfach zu erzeugen (1x Tab-Taste); gute Warnung, wenn der Code zu komplex wird (es geht über den Rand) Nachteile: bei komplexen Schleifen/if's geht es schnell über den Rand (Anm.: sowas sollte man sowieso vermeiden)
b) Einrückung == 1 oder 2 Spaces Vorteil: sehr verdichteter Code mit vielen Indent-Levels ist möglich Nachteile: es wird schnell unübersichtlich
c) öffnende Klammer { unter for, if, while, switch Vorteil: öffnende Klammer { kann sehr leicht der schließenden Klammer } zugeordnet werden Nachteil: es schafft künstlichen Abstand zwischen Code und for/if/... => Folge: der Lesefluß wird unnötigerweise unterbrochen
d) öffnender Klammer { dahinter Vorteil: keine Unterbrechung des Leseflusses Depends: } wird nun dem ersten Buchstaben des Statements statt { zugeordnet
usw.
Was Dir persönlich mehr liegt musst letztlich Du entscheiden. Ich fand Linus' Argumente sehr einleuchtend.
Your milage may vary.
Konrad