6

Is it bad practice to have a switch case in a switch case? If so, what are alternatives? I don't really want to use if/else if if I don't need.

Instead of doing some like:

if((this == 1) && (that == 1)){ //something }
else if((this == 1) && (that == 2)){ //something }
else if((this == 2) && (that == 3)){ //something }

I was thinking along the lines of:

switch(this){
    case 1:
        switch(that){
            case 1:
                // something
            break;
            ....
        }
    break;
    ....
}

It just looks really wrong to me. Not wrong in syntax but wrong in terms of proper practice.

sam-w
  • 7,478
  • 1
  • 47
  • 77
seroth
  • 581
  • 1
  • 9
  • 26
  • 2
    I can see cases where it's OK. But I'd stare at it pretty long and see if I could find a simpler technique. –  Aug 22 '13 at 12:59
  • Not actually a dupe, but has relevant/interesting info: http://stackoverflow.com/questions/7807970/nesting-switch-cases-in-javascript-any-speed-advantage – Joum Aug 22 '13 at 12:59
  • 1
    To get relevant answers it would be better to add your code to the question... – Joe Ratzer Aug 22 '13 at 13:01
  • Instead of doing some like: if((this == 1) && (that == 1)){ //something } else if((this == 1) && (that == 2)){ //something } else if((this == 2) && (that == 3)){ //something } I was thinking along the lines of: switch(this){ case 1: switch(that){ case 1: } break; } – seroth Aug 22 '13 at 13:07

6 Answers6

7

It's bad practise to have massive functions that do lots of different things. If you have a switch case in a switch case, that suggests your function is probably too big and you should consider splitting it up into smaller easier-to-understand chunks.

But there are no hard-and-fast rules; it all depends on the exact scenario.

user9876
  • 10,954
  • 6
  • 44
  • 66
4

Avoid following approach

switch(id)
{
    case 1:
    {
        switch (subid)
        {
            case 4:
                // nested code
        }
    }
    case 2:
         // some code
}

The preferable approach and improve your code by moving nested section into a method

switch(id)
{
    case 1:
        SubSwtich(subid);
        break;
    case 2:
         // some code
}

function SubSwtich(int subid)
{
        switch (subid)
        {
            case 4:
                // nested code
        }
}
usman allam
  • 274
  • 1
  • 5
3

i would consider it a bad pratice. in most cases this is unreadable.

you can extract the "sub" switch-cases to methods.

Philipp Sander
  • 10,139
  • 6
  • 45
  • 78
2

If it makes your code harder to read, then it's bad practice.

Whether that's the case in your particular example is up to you to decide, but in general I'd say it probably would be the case.

You asked for alternatives...

  1. Extract some of your code into a sub-function. Eg:

    case 'foo' :
        myVar = 'blah';
        break;
    case 'bar' :
        myVar = secondLevelFunction();
        break;
    

    Here, the secondLevelFunction() contains the additional switch() statement where each case returns a value for myVar.

  2. Use array mapping. Eg:

    var mapper = {'foo':'blah', 'bar':'bibble', etc};
    
    //now, instead of a big switch(input) { .... } block that sets myVar
    //for each option, you can just set it directly in a single line, like so:
    var myVar = mapper[input];
    

In addition, if you're looking for concrete measures of code quality, you should learn about Cyclomatic Complexity. This is a measure of how complex a function is. The measurement is taken by looking at how many "decision points" the function has. Each case, if, loop, etc is a "decision point". The more you have, the more complex your function.

Cyclomatic Complexity is stronly linked to code quality and good coding practices, so if your function has a high CC score (which it probably will do if it has multiple nested switch blocks), then it is a sign of poor code quality. Both the alternative solutions I described above can help with this. I'll leave it to you to read up more on CC.

Obviously the alternative solutions would need to be adapted to your needs, but hopefully they give you some ideas.

Spudley
  • 166,037
  • 39
  • 233
  • 307
0

Bad practice? No! A potential pain when it comes to troubleshooting, probably! See what you can do about turning all the 'options' into something more organized and commonly connected. Maybe even write your own function using method overloading determined by the number of parameters being sent.

Take a look at this SO post and see if it gives you some ideas.

Community
  • 1
  • 1
DevlshOne
  • 8,357
  • 1
  • 29
  • 37
0

You should break your code in differ routines where depending upon the switch statement, and in the routine you can continue to use switch case as well. Just like following.

private void Switch(int value)
    {

        switch (value)
        {
            case 1:
                SwitchNest(value);
                break;
            case 2:
                break;
        }
    }

    private void SwitchNest(int value)
    { 
        switch (value)
        {
            case 1:
                SwitchOtherMethod(value);
                break;
            case 2:
                break;
        }
    }
Ketan Panchal
  • 230
  • 1
  • 2
  • 9
  • A function for a one-time use, I would argue, is not worth it. Not to mention you're now jumping places within code to follow work-flow instead of one place. (From a readability standpoint, and this may be IMHO, I'd rather sift through nested switches than go chasing one-off functions.) – Brad Christie Aug 22 '13 at 13:07