Code Konvention for-Schleife / return

[Dragonfire]

Hey,
ich habe da mal eine Frage und zwar nicht zu einem korrekten Code,
sondern um den "Style".

Als einfach Beispiel dient jetzt mal eine einfache Methode, welches ein Palindrom festellen soll:

public static boolean isPalindrom(String word) {
		boolean palindrom = true;
		char[] c = word.toCharArray();
		for (int i = 0; i < c.length / 2 && palindrom; i++) {
			palindrom = c[i] == c[c.length - 1 - i];
		}
		return palindrom;
	}

Angeblich gibt es die Konvention,
dass die for-Schleife nur als Zählschleife dient und demnach meine Version mit
dem logischen und (palindrom) nicht ganz konform ist.

Habt ihr davon schon gehört?

Sollte man lieber einen Methodenausgang haben oder lieber mehrere?

Diese Diskussion würde mich mal interessieren.

 

[bone2]

http://www.oracle.com/technetwork/java/codeconventions-150003.pdf

keine einschränkung für deinen fall.

    public static boolean isPalindrom(String word) {
        boolean palindrom = true;
        char[] c = word.toCharArray();
        
        for (int i = 0; i < c.length / 2; i++) {
            palindrom = c[i] == c[c.length - 1 - i];
            
            if (! palindrom) {
                break;
            }
        }
        
        return palindrom;
    }

ist leicht besser verständlich, würd ich sagen

 

[Gast2]

ist auch nur leicht besser verständlich, würd ich sagen

Ich würde sagen: Deutlich einfacher zu lesen und zu verstehen.

Ich glaub auf den ersten Blick hätte ich das [c]&& palindrom[/c] schlichtweg übersehen.

 

[bygones]

Ich glaub auf den ersten Blick hätte ich das [c]&& palindrom[/c] schlichtweg übersehen.

jo...

zusätzliche Abbruchbedingungen in for schleifen find ich auch unschön, da gern übersehen. Ist aber keine Konvention eher meiner ansicht nach Gewohnheit

Ich würds glaub ich eher so schreiben:

    public static boolean isPalindrom(String word) {
        char[] c = word.toCharArray();
        
        for (int i = 0; i < c.length / 2; i++) {
            boolean identical = c[i] == c[c.length - 1 - i];
            
            if (!identical) {
                return false;
            }
        }
        return true;
    }

ich bin kein freund vom break... man sieht nicht direkt was nun passiert. Durch das return wird direkt kommuniziert wie der Fall zu behandeln ist. Auch die Variable palindrom braucht man nicht... wenn man durch die schleife durch ist ists true... nochmals schaun zu müssen welchen wert palindrom nun haben könnte ist zu viel.

break und continue sind 2 Keywords die a) unsinnig sind und b) vermieden gehören...

Der einzige Streitpunk hier ist, dass manche behaupten es darf nur einen return geben in einer methode. Dies find ich aber nicht (siehe oben)

EDIT: der algorithmus ist übrigens n bisschen ignorant... lass man Anna durchlaufen ;-)

 

[tfa]

Ich würde das Flag ganz rausschmeißen und das break durch "return false" ersetzen. Am Ende dann "return true". Das ist noch leichter zu lesen.

 

[Dragonfire]

Vielen Dank für die Antworten,

also ich kann jetzt immerhin nachvollziehen warum man Bedingungen nicht in
der for-Schleife packt ...
Mit den zwei Methodenausgängen geht es jetzt noch hier beim Beispiel.
Aber ich finde es kann schnell unübersichtlich werden.

 

[Andi_CH]

Zwei Methodenausgänge in kleineren Methoden ok obwohl ich lieber nur einen sehe 🙂 - spätestens bei einigen 100 Zeilen und 15 Methodenausgängen ;-) .... no go!

 

[AwsmDude]

Zwei Methodenausgänge in kleineren Methoden ok obwohl ich lieber nur einen sehe 🙂 - spätestens bei einigen 100 Zeilen und 15 Methodenausgängen ;-) .... no go!

Dann ist die ganze Methode ein no go. Ob nun mit mehreren return oder ohne...

 

[bygones]

spätestens bei einigen 100 Zeilen und 15 Methodenausgängen ;-) .... no go!

bei sowas sind mehrere returns dein kleinstes Problem.... da gehört die Methode bearbeitet und nicht "oh mehrere hundert Zeilen dann nehm ich mal lieber nur ein return"....

 

[MySelV]

Hi,

ich würde sagen bei einer 100-zeiligen Methode sind 15 Methodenausgänge nur das I-Tüpfelchen. Die Methode selbst ist schon viel zu lang.
Ich finde, dass man durchaus mehrere returns haben kann, schon weil es oft Einrückungen spart, wenn man

if (some == null) {
   return nullSollNichtSeinReturn;
}
// code
return ergebnis;

hat.

Sorry für OT
Erik

Edit: 2 parallele Antworten mit gleichem Inhalt sprechen wohl für sich 😉

 

[bygones]

@Erik
[c]return nullSollNichtSeinReturn;[/c] gibt es schon in Java und nennt sich Exception 😀

 

[ARadauer]

wenn ich was suche?
schleife... gefunden return true oder was auch immer... ist das klarste was es gibt..

 public int getIndex(String toSearch){
      for(int i = 0; i < list.size(); i++){
         if(toSearch.equals(list.get(i))){ //kann natürlich eine komplexe bedinung sein...
            return i;
         }
      }
      return -1; //oder exception...
   }

 

[Gast2]

Ob ein oder mehrer returns in einer Methode ist eine weitere Diskussion. Hier auch schon sehr ausführlich geführt: http://www.java-forum.org/java-basics-anfaenger-themen/102055-mehrere-return-befehle-methode.html

also ich kann jetzt immerhin nachvollziehen warum man Bedingungen nicht in
der for-Schleife packt ...

Aber die Durchlaufbedingung einer Schleife sollte meinem Geschmack nach möglichst einfach sein und auf den ersten Blick erkennbar - das ist sie bei dir nicht. Du veränderst ja zusätzlich zu einem evtl recht komplexen Ausdruck (in deinem Beispiel noch recht einfach) die Bedingung fortlaufend mit. Wenn da jetzt ein Fehler auftritt und die Schleife abbricht kannst du erstmal mit dem debugger ran und versuchen herauszubekommen welcher Teil den Schleifenabbruch verursacht.

for(int i = 0; i < globalArray.length / list.size(); i++){
   [...]
   if(blah){
       list.remove(someobject);
   } else {
       i = dosomethingCrazyWithI();
   }
   [...]
}

Das würde der der es programmiert auch verstehen und für total klar und übersichtlich halten - sind ja alles einfache Anweisungen... Ist es aber einfach nicht für jemanden der dann von draussen drauf guckt. Überlg mal was hier z.B. für ekelige Dinge passieren können? z.B. ein DivisionByZeroException in der Evaluation der Abbruchbedingung... *schüttel*

Je einfacher der Code zu lesen und zu verstehen ist desto bessr ist das.

 

[VfL_Freak]

Moin,

jo...
zusätzliche Abbruchbedingungen in for schleifen find ich auch unschön, da gern übersehen. Ist aber keine Konvention eher meiner ansicht nach Gewohnheit

da kann ich Dir nur beipflichten 🙂
Gleiches gilt rein optisch auch für die "Division durch 2", wie ich finde!
Ich würde das zumindest klammern oder die Berechung gleich VOR die Schleife ziehen :

public static boolean isPalindrom(String word) 
{
    char[] c = word.toCharArray();
        
    int iMaxLen = c.length / 2;
    for (int i = 0; i < iMaxLen; i++) 
    {
         boolean identical = c[i] == c[c.length - 1 - i];
         if (!identical) 
         {
              return false;
         }
    }
    return true;
 }

Aber - wie gesagt - nur aus Gründen der Lesbarkeit !!

Gruß
Klaus

 

[Dragonfire]

Echt eine interessante Diskussion^^
Dann werde ich mir es mal umgewöhnen,
Performancemässig sollte es ja egal sein 😉

 

[Gast2]

Performancemässig sollte es ja egal sein 😉

Mit sehr großer Sicherheit in keinem messbaren Bereich...