For Programmers: Free Programming Magazines  


Home > Archive > Java Help > January 2008 > [Switch ()... case]Sting variable









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author [Switch ()... case]Sting variable
Daniel Moyne

2008-01-12, 7:19 pm

Very likely this question is a classico ; I have a method that gets a
variable string menuItem as argument and I want to test the value against
some known strings ; so far I have proceded with the typical if ..else...
structure :
if (menuItem.equals("string_1") {
....
} else {
if (menuItem.equals("string_2") {
} else {
....
}
}
}

but I would rather use a switch ()... case structure that would bring more
readability to the code ; how can this be managed ?
Thanks.
Joshua Cranmer

2008-01-12, 7:19 pm

Daniel Moyne wrote:
> Very likely this question is a classico ; I have a method that gets a
> variable string menuItem as argument and I want to test the value against
> some known strings ; so far I have proceded with the typical if ..else...
> structure :
> if (menuItem.equals("string_1") {
> ....
> } else {
> if (menuItem.equals("string_2") {
> } else {
> ....
> }
> }
> }
>
> but I would rather use a switch ()... case structure that would bring more
> readability to the code ; how can this be managed ?
> Thanks.


The typical style is this:

if ("string_1".equals(menuItem)) {
} else if ("string_2".equals(menuItem)) {
} else {
}

(The inversion of the equals helps guard against the case where menuItem
is null).

Requests to allow Strings in switch statements have been proposed, but
to no avail as of yet.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Lew

2008-01-12, 7:19 pm

Joshua Cranmer wrote:
> The typical style is this:
>
> if ("string_1".equals(menuItem)) {
> } else if ("string_2".equals(menuItem)) {
> } else {
> }
>
> (The inversion of the equals helps guard against the case where menuItem
> is null).


This is "typical"?

There was a thread about this a while back. A number of people, myself
included, advise explicit tests for null rather than this idiom.

It is "typically" better to make explicitly sure that if null isn't allowed,
that it doesn't occur.

--
Lew
Joshua Cranmer

2008-01-12, 10:29 pm

Lew wrote:
> Joshua Cranmer wrote:
>
> This is "typical"?


The typicality I meant to confer was the if/else if/else if/else if/else
format. I merely like the inversion better (I think it also likes
somewhat nicer, a mere digression) as well.


--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Patricia Shanahan

2008-01-12, 10:29 pm

Daniel Moyne wrote:
> Very likely this question is a classico ; I have a method that gets a
> variable string menuItem as argument and I want to test the value against
> some known strings ; so far I have proceded with the typical if ..else...
> structure :
> if (menuItem.equals("string_1") {
> ....
> } else {
> if (menuItem.equals("string_2") {
> } else {
> ....
> }
> }
> }
>
> but I would rather use a switch ()... case structure that would bring more
> readability to the code ; how can this be managed ?
> Thanks.


If it is an error for menuItem to not be one of the alternatives, you
could define an enum with values string_1, string_2 etc.

switch(MenuEnum.valueOf(menuItem)){
case MenuEnum.string_1:
...

Patricia
Roedy Green

2008-01-12, 10:29 pm

On Sat, 12 Jan 2008 22:20:26 +0100, Daniel Moyne <dmoyne@tiscali.fr>
wrote, quoted or indirectly quoted someone who said :

>
>but I would rather use a switch ()... case structure that would bring more
>readability to the code ; how can this be managed ?
>Thanks.


Use enums. Use enum valueOf to convert a String to an enum, then use
a switch. See http://mindprod.com/jgloss/enum.html
--
Roedy Green, Canadian Mind Products
The Java Glossary, http://mindprod.com
Daniel Moyne

2008-01-13, 8:19 am

Joshua Cranmer wrote:

> Daniel Moyne wrote:
>
> The typical style is this:
>
> if ("string_1".equals(menuItem)) {
> } else if ("string_2".equals(menuItem)) {
> } else {
> }
>
> (The inversion of the equals helps guard against the case where menuItem
> is null).
>
> Requests to allow Strings in switch statements have been proposed, but
> to no avail as of yet.

Joshua,
thanks for this trick allowing to skip the problem of menuItem as a null
case which of course otherwise as to be tested first.
Daniel Moyne

2008-01-13, 8:19 am

Daniel Moyne wrote:

> Very likely this question is a classico ; I have a method that gets a
> variable string menuItem as argument and I want to test the value against
> some known strings ; so far I have proceded with the typical if ..else...
> structure :
> if (menuItem.equals("string_1") {
> ....
> } else {
> if (menuItem.equals("string_2") {
> } else {
> ....
> }
> }
> }
>
> but I would rather use a switch ()... case structure that would bring
> more readability to the code ; how can this be managed ?
> Thanks.

Thanks to everybody for your help ; somehow I knew that an enum instance
would be proposed but not on which form ; enum is really an Java animal
that shows how Java can in some cases reach a high level of abstraction.
Lew

2008-01-13, 7:21 pm

Daniel Moyne wrote:
> thanks for this trick allowing to skip the problem of menuItem as a null
> case which of course otherwise as to be tested first.


Why would having to test for null separately be a problem?

--
Lew
Daniel Moyne

2008-01-13, 7:21 pm

Lew wrote:

> Daniel Moyne wrote:
>
> Why would having to test for null separately be a problem?

It is not a problem Lew but il allows for code simplification where a null
test would normally lead to no action at all ; on the other hand if a null
test has some particular meaning for some specific action requested then I
agree with you : such test has to be done first with else for the rest of
the code.


Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com