Entwicklungsvorgaben

Softwareentwicklung: Entwicklungsvorgaben

Allgemeine Softwareentwicklung - Andere Programmiersprachen, Regex, OOP, Design Patterns

Erstellt von cousa  |  Antworten: 10

  1. #1
    cousa


    Entwicklungsvorgaben
    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?
    Java Code:
    1.  
    2. public boolean berechneStatus(Objekt basis,Objekt erweiterung){
    3. if (basis== null||erweiterung == null){
    4. return false;
    5. }
    6. if(basis.getWert()== null){
    7. throw new Exception("msg");
    8. }
    9. //hier findet die lange Berechnung statt
    10. return true;
    11. }

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



    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

  2. #2
    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...

  3. #3
    Gast2

    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.

  4. #4
    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?

  5. #5
    Gast2

    Das tritt ein wenn die if Bedingung zutrifft

  6. #6
    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.

  7. #7
    maki

    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.

  8. #8
    cousa


    Zitat Zitat von maki Beitrag anzeigen
    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

  9. #9
    maki

    Zitat Zitat von cousa Beitrag anzeigen
    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...

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

    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.

  11. #11
    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.


Keine Antwort auf Deine Suche gefunden? Registriere Dich kostenlos und stelle Deine eigene Frage zu Java!

Jetzt kostenlos registrieren