Beispiel 1 oder Beispiel 2?

Beispiel 1:

int ret1 = foo_1 ( );
if(ret1==0){
cout<<"error 1 "<<endl;
}

int ret2 = foo_2 ( );
if(ret1==0){
cout<<"error"<<endl;
}

int ret3 = foo_3 ( );
if(ret==0){
cout<<"error 2 "<<endl;
}

int ret4 = foo_4 ( );
if(ret==0){
cout<<"error 3"<<endl;
}

Beispiel 2:

int ret1,ret2,ret3,ret4;

ret1 = foo_1 ( );
if(ret1==0){
cout<<"error 1 "<<endl;
}

ret2 = foo_2 ( );
if(ret1==0){
cout<<"error"<<endl;
}

ret3 = foo_3 ( );
if(ret==0){
cout<<"error 2 "<<endl;
}

ret4 = foo_4 ( );
if(ret==0){
cout<<"error 3"<<endl;
}

Generell gilt:
* Variablen immer initialisieren
* Variablen erst dort deklarieren, wo man sie benötigt.

Beides ist im zweiten Beispiel nicht gegeben.

Welchen Schreibweise findet ihr besser?

Wenn man mal von fehlenden Einrückungen absieht (die ebenso sehr wichtig sind): 1

P.S: Ich finde den Stil von dir zudem etwas ungewohnt, so z.B. vor einem öffnenden "{" kein Leerzeichen, vor einem "()" aber schon (Wenn schon unterschiedlich geregelt, kenne ich das eher anders herum).

Beispiel 2 sieht nach C89 aus

Die Codeinrueckungen sind in beiden Beispiel zum heulen :p

Das Problem ist, dass du den Rückgabewert nutzt um einen Fehler festzustellen. Das macht man in C++ nicht und schon gar nicht 4 mal hintereinander.
Für das gibt es ein Sprachmittel, das sich Exceptions nennt.

if(!foo_1 ( ))
    cout << "error in foo_1\n";

if(!foo_2( ))
    cout << "error in foo_2\n";

if(!foo_3( ))
    cout << "error in foo_3\n";

if(!foo_4( ))
    cout << "error in foo_4\n";

(Hab das endl mal weggemacht).

Generell gilt: Variablen überhaupt erst deklarieren, wenn man sie zum lesbarer-machen des Codes oder zur Wiederverwendung benötigt.
In deinem Beispiel aber benutzt man normalerweise exceptions.

//Deklarationen immer am Anfang und getrennt soweit möglich
//d.h. wenn später erst benötigt...
int ret1 = 0;

int ret1 = foo_1();
int ret2 = foo_2();
int ret3 = foo_3();
int ret4 = foo_4();

// Dann der ganze scheiß
if (ret1 == 0) {
  cout << "error 1 " << endl;
}

if (ret1 == 0) {
  cout << "error" << endl;
}

if (ret == 0) {
  cout << "error 2 " << endl;
}

if (ret == 0) {
  cout << "error 3" << endl;
}

Der Beitrag vor diesem ist eher schlechter Programmierstil den ich leider
trotzdem verfolge ;P

regel: egal ob nach einem if else while for etc nur eine anweisung kommt
trotzdem die geschweiften klammern hinknallen

Wird hier etwa schon die Einrückung kritisiert? Wenn wir schon beim Unwichtigen sind, wieso nicht noch das ==0 ?

Das Problem ist, dass du den Rückgabewert nutzt um einen Fehler festzustellen. Das macht man in C++ nicht und schon gar nicht 4 mal hintereinander.
Für das gibt es ein Sprachmittel, das sich Exceptions nennt.

Nur weil es in C++ Exceptions gibt heisst das nicht das man sie verwenden muss. Diesen Zwang kenne ich nur von Java und bin persönlich ganz froh das es in C++ kein Zwang ist...

regel: egal ob nach einem if else while for etc nur eine anweisung kommt
trotzdem die geschweiften klammern hinknallen

Das ist die Anfängerregel...

Ausserdem kompiliert dein Code oben nicht.

realKoala schrieb:

regel: egal ob nach einem if else while for etc nur eine anweisung kommt
trotzdem die geschweiften klammern hinknallen

Das ist die Anfängerregel...

Ausserdem kompiliert dein Code oben nicht.

muss er auch nicht ^^
ging ja um stil nicht um lauffähigkeit

Außerdem ist mangelnde Lauffähigkeit in der Programmierung ziemlich schlechter Stil.

errata schrieb:

Wird hier etwa schon die Einrückung kritisiert? Wenn wir schon beim Unwichtigen sind, wieso nicht noch das ==0 ?

Das Problem ist, dass du den Rückgabewert nutzt um einen Fehler festzustellen. Das macht man in C++ nicht und schon gar nicht 4 mal hintereinander.
Für das gibt es ein Sprachmittel, das sich Exceptions nennt.

Nur weil es in C++ Exceptions gibt heisst das nicht das man sie verwenden muss. Diesen Zwang kenne ich nur von Java und bin persönlich ganz froh das es in C++ kein Zwang ist...

Sind dir Exceptions zu kompliziert oder was? Jeder normale C++-Programmierer würde Exceptions der obigen Methode vorziehen, wenn es Sinn macht (bei manchen Fehltritten muss ja nicht gleich was geworfen werden).

Sind dir Exceptions zu kompliziert oder was? Jeder normale C++-Programmierer würde Exceptions der obigen Methode vorziehen, wenn es Sinn macht (bei manchen Fehltritten muss ja nicht gleich was geworfen werden).

Nein sind mir nicht zu kompliziert. Aber wie Du selbst schreibst: wenn es Sinn macht...

Hacker schrieb:

Sind dir Exceptions zu kompliziert oder was? Jeder normale C++-Programmierer würde Exceptions der obigen Methode vorziehen, wenn es Sinn macht (bei manchen Fehltritten muss ja nicht gleich was geworfen werden).

Nein sind mir nicht zu kompliziert. Aber wie Du selbst schreibst: wenn es Sinn macht...

Es macht oft Sinn.

da es um stil geht... hier mal eine saubere:

Die sowas von dreckig ist, das ich hoffe das du das nur Ironisch meinst.

realKoala schrieb:

//Deklarationen immer am Anfang und getrennt soweit möglich
//d.h. wenn später erst benötigt...

Diese Aussage ist einfach nur daneben, und wird so eigentlich wenn überhaupt nur noch in alten Büchern gelehrt.

Deklarationen gehören erst dahin, wo man sie benötigt. Das vereinfacht beispielsweise auch ein Refactoring, da die Abhängigkeiten in der Regel wesentlich näher stehen. Es erlaubt eine bessere funktionelle Trennung...

Es hindert einen übrigens auch in Java nichts daran, Integer oder Bools zurückzugeben, statt eine Exception zu werfen. Es ist gelegentlich sogar sinnvoll, das zu tun.

Grundsätzlich gibt es Fälle in denen es sinnvoll ist, aber ich würde hier zwischen echten Fehlern und reinen Statusinformationen unterscheiden. Letztere sind imho vor allen dann okay, wenn es kein Fehler darstellt, diese nicht zu überprüfen (Programmierer sind durchaus Schreibfaul und vergessen zudem gerne Statusprüfungen - Wenn wiederum Exceptions fliegen, wird man diese recht schnell versuchen auszumerzen oder zu prüfen ob es eine sinnvolle Behandlung gibt...