Frage zu Switch-Anweisung

[Luk10]

Grüße,

Ich frage mich grade ob switch wirklich alle primitiven Datentypen nimmt (inklusive Arrays) oder nur bestimmte aus den primitiven Datentypen.
Gibt es auch andere Datentypen die genommen werden?

Wenn es ein switch über Arrays gibt wie habe ich mir das vorzustellen und was sind die "cases"?

Danke,
-Luk10-

 

[eRaaaa]

Wie kommst du darauf dass Arrays primitive Datentypen sind?
Und was switch alles annimmt steht in jedem guten Java Buch. In Java 7 gab`s allerdings eine kleine Änderung was Strings betrifft, aber auch das lässt sich nachlesen bei google

 

[Luk10]

Gut, wenn Arrays keine primitiven Datentypen sind hat sich das geklärt ...

In Java ist auch eine Insel (Galileo Open) steht nur

Sie vergleicht nacheinander den Ausdruck hinter dem switch (ein primitiver Typ wie byte, char, short oder int) mit jedem einzelnen Fallwert

Wäre also froh wenn mir das jemand bestätigen könnte oder spezifizieren.

Danke,
-Luk10-

 

[eRaaaa]

enums und WrapperKlassen wie Integer und co gehen auch und eben auch Strings seit 7

The switch Statement (The Java™ Tutorials > Learning the Java Language > Language Basics)

 

[Luk10]

Danke! Eine Frage noch: In meine Schulbuch steht folgendes:

case 0: {tuDies();} break;

Wie ist das mit den geschweiften Klammern? ... deinem Link zufolge kann man die auch weglassen. Kann ich sie aber auch hinschreiben?

Was für einen Sinn macht es, beide Möglichkeiten zuzulassen?

Danke,
-Luk10-

 

[Marco13]

Da könnte man halb-Argumente aufzählen, wie "ist übersichtlicher" oder so... ein "driftiger" Grund könnte (!) sein, dass man in den Klammern Variablen hat

case 0: {
    int x = 123;
    tuDies(x);
} 
break; 

case 1: {
    int x = 234; // Nochmal x, aber keine Meldung "...has already been declared"
    tuDies(x);
} 
break;

Ist aber IMHO stilistisch fragwürdig...

 

[Michael...]

Wie ist das mit den geschweiften Klammern? ... deinem Link zufolge kann man die auch weglassen. Kann ich sie aber auch hinschreiben?

ausprobieren ;-)

Was für einen Sinn macht es, beide Möglichkeiten zuzulassen?

Bei

(a + b) + c

oder

((a + b))*2

machen die Klammern auch nicht unbedingt Sinn, sind aber trotzdem nicht falsch.

 

[Andi_CH]

Da könnte man halb-Argumente aufzählen, wie "ist übersichtlicher" oder so... ein "driftiger" Grund könnte (!) sein, dass man in den Klammern Variablen hat

case 0: {
    int x = 123;
    tuDies(x);
} 
break; 

case 1: {
    int x = 234; // Nochmal x, aber keine Meldung "...has already been declared"
    tuDies(x);
} 
break;

Ist aber IMHO stilistisch fragwürdig...

Was ist daran fragwürdig? Dass x wiederholt definiert wurde oder das zweimal genau derselbe Code steht?

Was ist mit:

case 0: {
    int x = 123;
    tuDies(x);
}
break;

case 1: {
    float x = 234;
    tuEtwasAnderes(x);
}
break;

ausprobieren ;-)

Bei

(a + b) + c

oder

((a + b))*2

machen die Klammern auch nicht unbedingt Sinn, sind aber trotzdem nicht falsch.

Es ist IMO absolut zulässig Klammern zu setzen um die Lesbarkeit zu verbessern, auch wenn der Kompiler ohne diese klar kommt. Egal ob das ( oder { ist.

 

[Andi_CH]

Das war ein Fehler ;-) Sorry

 

[Luk10]

Danke für die Antworten!
/closed

-Luk10-

 

[Marco13]

Was ist daran fragwürdig? Dass x wiederholt definiert wurde oder das zweimal genau derselbe Code steht?

Bei dieser Stilfrage (!) ist das "IMHO" besonders wichtig: Ich würde es überhaupt vermeiden, eine lokale Variable in einem case-Block zu definieren. Und ich würde auch versuchen, zu vermeiden, dort mehr als eine Zeile reinzuschreiben. Überhaupt finde ich, dass es bei etwas höher-leveligem OOP nur wenige Stellen gibt, wo man ein switch sinnvoll einsetzen kann :bahnhof: (irgendwas mit enums, manchmal). Aber nochmal: Alles IMHO

 

[maki]

^^ Nicht nur deiner Meinung nach Marco13

In "Clean Code" werden einige Dinge zu switch/case statements gesagt (hässlich weil immer groß, etc. pp.), laut Bob Martin sollte in den einzelnen case blöcken nur 2 Dinge stehen: 1. Methodenaufruf (nie direkt im case block machen sonst wird es noch größer) und ein break.

Und am besten ganz tief im Code verstecken