Klammern hinter Bedingungen / Schlüsselwörtern
-
verstehsnicht schrieb:
Ich gehöre zu den Leuten die so programmieren
if(A) { // } else { // }Das finde ich übersichtlich und man sieht sofort welche Blöcke wo beginnen und wo enden. Viele machen das aber so
Wenn man aber es so schreibt:
if(A) { // } else { // }Spart man sich einige Zeilencode ein, was meines Erachtes der Übersichtlichkeit bei langen Passagen noch besser hilft, da man so mehr Code auf einen Bildschirm kriegt und nicht ständig scrollen muss.
Für Übersichtlichkeit ist meines Erachtens auch Einrücken auch viel wichtiger, wenn man das fleißig macht ist es doch auch egal wie man es schreibt, da man sofort sieht was ein Block ist.
-
imhotep schrieb:
verstehsnicht schrieb:
Ich gehöre zu den Leuten die so programmieren
if(A) { // } else { // }Das finde ich übersichtlich und man sieht sofort welche Blöcke wo beginnen und wo enden. Viele machen das aber so
Wenn man aber es so schreibt:
if(A) { // } else { // }Spart man sich einige Zeilencode ein, was meines Erachtes der Übersichtlichkeit bei langen Passagen noch besser hilft, da man so mehr Code auf einen Bildschirm kriegt und nicht ständig scrollen muss.
Für Übersichtlichkeit ist meines Erachtens auch Einrücken auch viel wichtiger, wenn man das fleißig macht ist es doch auch egal wie man es schreibt, da man sofort sieht was ein Block ist.Es ist ja nun mal so dass es empfohlen wird den Quellcode einer Funktion/Methode nicht ueber eine Seite wachesen zu lassen, wenn das geschieht sollte man sofort Refactern (Code neu gestalten).
Meiner Meinung traegt das sehr viel mehr zur Lesbarkeit des Codes bei als irgendeine schreigweise wieif ( A ) { } oder if ( B ) { }Im grunde ist es aber wirklich nur geschmacksache. Vor allem wenn man an einzelprojekten arbeitet wo man wirklich nur alleine mit dem Code arbeitet kann man sich das einteilen wie man will.
Bei groesseren Projekten, ich nehm jetzt mal das Gnome Projekt her, werden die Regeln zur Programmierweise vorgeschrieben und man 'muss' (eigentlich nur sollte) daran halten. Da es aber fast alle machen halten sich auch fast alle daran.
Nun zu meinem Schlusssatz: Ich verwende Option A bei der JavaProgrammierung und Option B bei C/C++ usw., wie gesagt, reine Geschmackssache.mfg
-
Dann käme wohl noch die nächste frage auf den Tisch: Wie sehen die Einrückungen bei Klammern auf gleicher Höhe aus?
if (A) { //Klammer in der gleichen Spalte, aber Text eingerückt } if (B) { //Klammer eingerückt und Text nochmal eingerückt } if (C) { //Klammern eingerückt und Text auf gleicher Höhe wie die Klammern } if (D) { //garnicht einrücken - ihgitt }Nuja, D dürfte ja mehr oder weniger außer Frage stehen. A und B hab ich schon des öfteren gesehn, wobei ich B für doppelt gemoppelt halte, es verbraucht außerdem mehr Platz als nötig. ein persönlicher Favorit ist C, man hat den gesamten Unterblock mitsamt den dazugehörigen Klammern auf einer Höhe. Das geht dann im Notfall auch konform mit Einzeilern:
if (A) return nix(); else { //hier kann jetzt mehr stehen, auch wenn das else //grade unnötig war... }
-
ich bin eher für Variante A, da ja der Code und nicht die Klammern im Vordergrund stehen sollen.
-
A und gut
-
ich benutze ebenfalls Variante A
-
Habe ganz früher auch mal B benutzt und fand das besser als A, aber inzwischen finde ich A definitiv besser.
-
Ich verwende normalerweise Variante A (oder teilweise auch A'):
if(bedingung) { // Block eingerückt, Klammern auf selber Ebene wie "Vater" } else { // Block ebenfalls eingerückt } // Einzelanweisungen: if(bedingung) cout<<"Ja"<<endl; // Anweisung eingerückt(bei kurzen Anweisungen oder Debug-Ausgaben kann es schon vorkommen, daß sie auf der selben Zeile wie die Kontrollanweisung landen, bei längeren Blöcken kommt meist ein "//if(bed)" oder "//for(i)" hinter die schließende Klammer)
-
pumuckl schrieb:
if (B) { //Klammer eingerückt und Text nochmal eingerückt }Ich kenne nur ein einziges Programm, das default-maessig den Style anwendet, und das ist der gute alte Emacs. War lange Zeit mein Lieblingsprogramm zum C/C++ proggen.
Heute, in zeiten von moderneren Entwicklungsumgebungen benutzt ich aber wie schon gesagt hauptsaechlich Option A (bzw. A').
-
LOL, ich glaub ich hab gerade ein Deja Vu.