String-Vergleiche mit konstanten Strings

Java-Forum Java-Grundlagen
#1

Leicht OT, aber:

Würde ich genau gegenteilig sehen. Yoda-Conditions lesen sich meistens schlechter und „verstecken“ den Null-Check. Zumindest bei mir gibt’s eigentlich nur zwei Fälle: der Wert darf null sein, dann sollte es ganz explizit da stehen, oder ich rechne nicht damit, dass der Wert null sein könnte, dann soll die NPE fliegen und meinen Fehler anzeigen. Für den nächsten der’s liest ist dann auch explizit, und er muss nach dem if nicht rätseln, ob der Wert jetzt null sein könnte oder nicht.

Mehrere Stringwerte zum Vergleichen in if-else übergeben
#2

Die Reihenfolge ist formal logisch egal, wenn man sich an den Contract von equals hält.
Solche „Optimierungen“ sind mir dabei recht egal, das sie Gegebenenfalls so oder so eventuell wegoptimieren, wer weiß das schon :man_shrugging:

#3

@Clayn Schau dich etwas in den offiziellen Implementierungen um, die String-Literale stehen immer vorne (eben damit keine ungewollte NPE auftritt).

Also NICHT:
someString.equals("abc")
sondern:
"abc".equals(someString)

#4

Du meinst vermutlich eher mich und nicht @Clayn…

Einigen wir uns drauf, dass das JDK als „offizielle Implementierung“ zählt?

jdk$ grep -nr '"\.equals(' . | wc -l  
    1802
jdk$ grep -nr '\.equals("' . | wc -l  
   10295

Ist allerdings leicht unfair, weil der Großteil der String-Vergleiche in Tests vorkommen, also mal ohne Tests:

jdk$ grep -nr '"\.equals(' src | wc -l
     804
jdk$ grep -nr '\.equals("' src | wc -l
    3358

String-Literale scheinen wohl doch nicht „immer vorne“ zu stehen…

#5

Und ich halte eure Diskussion in einem Thema im Java-Grundlagen Subforum - von einer Person die offensichtlich noch versucht die absoluten Basics zu verstehen - nicht nur für Offtopic sondern für komplett kontraproduktiv.

1 Like