To switch or not to switch, that's the question....
-
Found in the sourcecode of an online questionnaire:
switch (eventPar) {
case 'Q402489A[0]': OptionChanged(eventPar);break;
case 'Q402489A[1]': OptionChanged(eventPar);break;
case 'Q402489A[2]': OptionChanged(eventPar);break;
case 'Q402489A[3]': OptionChanged(eventPar);break;
}Why on earth would you do this?
-
It depends whether eventPar can only take those values listed in the switch block. Maybe they wanted to call OptionChanged only for those values and not others?
Still, there are better ways of doing it.
-
I like the repeated calls to OptionChange(eventPar), even though that's the same outcome for all switch matches. I also like the unnecessary break on the last case block. The lack of a default case is particularly sweet too :)
The array dereferencing syntax makes me suspect that those apostrophes shouldn't be there.
-
@pinkduck said:
The array dereferencing syntax makes me suspect that those apostrophes shouldn't be there.
They have to. A switch statement can only take constants (disclaimer: I'm talking out of my ass).
-
@pinkduck said:
The array dereferencing syntax makes me suspect that those apostrophes shouldn't be there.
I'm guessing that those are names of the controls.
-
@Zecc said:
@pinkduck said:
The array dereferencing syntax makes me suspect that those apostrophes shouldn't be there.
They have to. A switch statement can only take constants (disclaimer: I'm talking out of my ass).
A switch statement can take more than just constants in most languages I've worked with. The final break is necessary, in particular, in C# (my current language of personal choice for ad hoc development). The only thing I can't explain is why the programmer didn't fall through with all four cases into the bottom. Or, alternatively, why he didn't use an if statement. This is just a gross misuse of the switch statement.
-
"Online questionnaire" makes me think the snippet was JavaScript, which is a loosely-typed language.
-
@pinkduck said:
I like the repeated calls to OptionChange(eventPar), even though that's the same outcome for all switch matches. I also like the unnecessary break on the last case block. The lack of a default case is particularly sweet too :)
The array dereferencing syntax makes me suspect that those apostrophes shouldn't be there.
If there's nothing to do in the default case, then there's no need for a default case. That whole "you must include a default case!" rule is predicated on the assumption that some default processing must needs occur anytime a switch is used. The assumption is faulty. The ivory-tower academics would force you to include an empty default case, which is utter rubbish, as its a GNDN.
-
It depends if the switch statement is over an exhaustive list of conditions. I don't know if that's the case here, but I get the feeling it is from the name of the variable. We can but guess :)
-
Hi, long reader, first post blah blah..
English is not my mother tongue so please blah blah
Maybe there are cases on some questions where the result of the switch is different from an answer to another.
I did code a generic e-learning web based piece of software long time ago,It had to handle user-customed list of questions and hierarchical structure ( like, don't ask Hard questions if the user failed on the obvious ones.. ),and when you have to handle different events when a user selects an answer ( like, start an animation, hide/show something, play a tune, whatever.. ), it is usually handled via properties attached to the answer description in the database.
In the end, the client side code ( javascript ) is not written by humans, but generated by the server app, answer by answer.
Nobody cares if it is unreadable or WTFed, it works as expected, nobody will ever read it, even for debugging purposes, because it has in fact been produced in a clear, logical, modular way from the server side P.o.w (thus being easy to maintain ).
Of course, if this Jscript has been written by some real human, or hardcoded in some way, well hu.. ok, it is frightening
-
@MustBeUsersFault said:
Nobody cares if it is unreadable or WTFed, it works as expected, nobody will ever read it
Are you sure that you're a long-time reader? Because if there's Javascript on a page, you'd better believe that somebody's going to read it for the off chance that they might be able to post it here. :)
-
@pinkduck said:
I also like the unnecessary break on the last case block.
The unnecessary break is valid syntactic sugar; it protects against forgetting to add a break before adding a new case block.
-
@rbowes said:
Are you sure that you're a long-time reader? Because if there's Javascript on a page, you'd better believe that somebody's going to read it for the off chance that they might be able to post it here. :)
Haha i know that, it's just that i've once seen ( and in a way, produced ) WTFed Javascript that was WTFed for a good/explanable ( does this word exist ?) reason and no consequences.
-
@pinkduck said:
I also like the unnecessary break on the last case block.
Haven't done much programming, have you?
-
Perhaps I was a little harsh with that point. I tend to take greater care coding than most so look out for ending break conditions in statement blocks when editing. I have done years of JavaScript and server-side programming by the way. It may well be generated at server-side in which case it probably wasn't worth the effort in altering the presence of the final 'break;'
