Entwicklungsvorgaben

[cousa]

Hallo Forum,
inspiriert durch den "schockierenden" Eintrag über den VB Entwickler in der Plauderecke habe ich mir einige Gedanken über meinen eigenen Programmierstil gemacht. Insbesondere gibt es bei uns zwei "feindliche Guppen" Entwickler was einige Stille bzw. Vorgehensweisen angeht.

Wie macht Ihr das bzw. was findet ihr sauberer?

Methode früh raus oder if else bis zum Ende?

1
2
3
4
5
6
7
8
9
10
public boolean berechneStatus(Objekt basis,Objekt erweiterung){
  if (basis== null||erweiterung == null){
    return false;
  }
  if(basis.getWert()== null){
     throw new Exception("msg");
  }
  //hier findet die lange Berechnung statt
  return true;
}

1
2
3
4
5
6
7
8
9
10
11
public boolean berechneStatus(Objekt basis,Objekt erweiterung){
  if (basis!= null&&erweiterung != null){
    //viele viele Zeilen 
   if(basis.getWert==null){
     throw new Exception("msg");
   }
 }else{
  return false;
 }
return true;
}

Wird klar was ich versuche auszudrücken?

Entweder möglichst schnell raus aus der Methode und so eine oder sogar mehrere If Ebenen zu sparen oder ist der Weg übersichtlicher eine IF Else und dann nach teilweise 40 Zeilen ein [JAVA] }else{ return false; }. Ist es nicht schöner einfach prüfen und raus? Aber wenn irgendwann im else Zweig doch noch Berechnungen hinzugefügt werden wird es schnell unübersichtlich.Aber auch hier versuche ich so schnell wie es geht wieder aus der Methode rauszukommen.

Habt Ihr noch solche "Streitpunkte" oder was sind eure kuriosesten Vorgaben/Eigenheiten bei der Entwicklung?

Schönen Sonntag!

cousa

[Xandaros]

Ich würde in dem Fall das return nach oben setzen, da es meiner Meinung nach übersichtlicher ist.

Irgendwie kommt es mir komisch vor so wenig zu posten, aber ich habe dem nichts mehr hinzuzufügen...

[EikeB]

Ich finde beide Varianten nicht unbedingt schön. Soll der boolean angeben ob die Berechnung möglich war oder nicht? Dann lieber ne Exception werfen für den Fall dass die Parameter nicht korrekt übergeben wurden.
Generell halte ich es auch für ok die Methode am Anfang oder mitten drin mit nem return zu verlassen, da Methoden eh kurz und übersichtlich sein sollten. Ob das für deine 40-50 Zeilen lange Methode auch gilt kann man schlecht sagen ohne die mal zu sehen, aber die kann man vermutlich auch noch in kleinere Methoden aufteilen, gerade wenn du größere if-else blöcke hast.

[bygones]

wie schon gesagt wurde, da Methoden so kurz wie moeglich bzw noetig gehalten werden sollen, ist es eher egal, da man die Methode so und so mit einem Blick ueberschauen kann.
Dein 2. Code ist aber so und so komisch. Wenn die Bedingung nicht true ist, geht er in den else zweig und returned false, danach kommt noch ein return true ?! Wann soll das eintreten?

[EikeB]

Das tritt ein wenn die if Bedingung zutrifft

[Tomate_Salat]

Variante 1. Ich finde zu viele verschachtelungen unschön und es ist imho einfacher zu lesen. Varianate 1 scheint sogar (eine stille) konvention bei uns im Betrieb zu sein.

[maki]

Zitat:

	Entweder möglichst schnell raus aus der Methode und so eine oder sogar mehrere If Ebenen zu sparen oder ist der Weg übersichtlicher eine IF Else und dann nach teilweise 40 Zeilen ein [JAVA] }else{ return false; }.

Keine der Varianten ist "sauber" wenn die Methode 40 Zeilen hat...

Wie schon gesagt wurde, halte die Methoden kurz, sehr kurz.

[cousa]

Zitat: maki

	Keine der Varianten ist "sauber" wenn die Methode 40 Zeilen hat... Wie schon gesagt wurde, halte die Methoden kurz, sehr kurz.

Das ist bei meinem code auch Standard. Ist leider ein "Alt System" das nicht sehr robust entwickelt worden ist.

cu cousa

[maki]

Zitat: cousa

	Das ist bei meinem code auch Standard. Ist leider ein "Alt System" das nicht sehr robust entwickelt worden ist.

Dann verstehe ich die Frage nicht...

[MasterK]

Variante 1. Natürlich sollte eine methode immer so kurz sein, dass sich die frage gar nicht stellt, aber das ist in der realität nunmal nicht immer sinnvoll machbar. Manchmal ist eine methode eben 80 zeilen lang, und es macht nicht immer sinn diese dann künstlich aufzusplitten. Und in dem fall ist es schön, wenn man sozusagen "vorbedinungen" gleich zu beginn der methode sieht und nicht irgendwo mittendrin aus der methode gesprungen oder abgebrochen wird.

Dennoch ist variante 2 auch objektiv gesehen nicht "falsch" und ich würde solchen code problemlos akzeptieren.

Übel wirds erst, wenn spezies kommen die sowas hinrotzen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public boolean machwas(){
 
  boolean ret = true;
  do {
    //...
    if (...) {
      ret = false;
      break;
    }
    //... mehr logik
    if (...) break;
 
    //usw, am besten über 500 zeilen
 
  } while(false);
  // blabla
  return ret;
}

Sowas habe ich das erste mal bei einem bei mir auf arbeit gesehen (der wirklich nur so programmiert mit hunderte zeilen langen methoden), aber danach auch mal hier im forum. Wer sowas schreibt, gehört geschlagen, pausenlos.

[nocturne]

Die schnelle Fehlerbehebung muss doch das Ziel sein! Also können wir die Frage nur anhand des Stacktraces lösen.
Ich zum Beispiel nehme gerne NPE in kauf, so kann man am schnellsten ableiten wo der Fehler liegt.