How to avoiding writing switch-case too long?

Question

In my current project, there are lots of code using switch statements with too many cases.

Switch(c)
{
case CASENUMBERONE:
//50-100 lines of code in each code
...
case CASENUMBERTWENTY:
..
}


//thousands of lines of macro definition in another file
#define CASENUMBERONE 1
...
#define CASENUMBERTWENTY 20
...

It seems not reasonable programming style. How to avoid this?

Answer 1

I think you should create separate methods for each case, and call them as per requirement.

Answer 2

Depends.

• You could write a function for each case. You can inline them if you're concerned about performance, but in real life, you may actually end up with a performance gain by having separate functions due to better instruction cache coherence.

• You could create a jump table if all your possible integer values are close by and pretty dense. That's what many compilers internally do for switch/case if certain conditions are met. The jump table is an array of function pointers, and the integer is an index into it. Obviously, you need to do bounds checking and NULL checks.

• You could redesign your code to use polymorphism and call a virtual function instead.

Answer 3

I wouldn't say that style seems reasonable. Given that you haven't given us much to go on, all I can do is generalise. Put each "case" into a separate function rather than inline in the switch. You could go as far as to create an array of function pointers which reference each of those functions for the given cases, but that depends on the cases you're covering. You could also use object-orientation and polymorphism to call each function for you.

I find it hard to believe that you wouldn't find any commonality across those cases.

Answer 4

As @Zain says, factor out the code for each case as a function/method (this isn't general advice, but advice for overly long functions).

In addition, consider using e.g. an array of function pointers.

Then you can just say handler[c]() :-)

Even better, chances are that the cases are not really a good approach to the original problem.

Perhaps using a base type with virtual methods would help (not using that is a common cause of inordinately long and absurd switch statements).

Cheers & hth.,

Answer 5

I agree with your assessment that code is not well written. You will either have to rewrite the legacy code using good techniques or provide an abstraction layer that effectively hides the bad code; this way you can rewrite the bad code at your leisure and the abstraction layer will tie your new, good code with the legacy code.

As always, you should write tests for every I/O pair to those functions to find out where to split them and how they tie together; tests will also allow you to refactor with near impunity.

It's too bad older C++ code is littered with style like this :/

Answer 6

1500 lines = (50-100 lines per case) * 20

you're absolutely right. it's not reasonable.

the method/function attempts to do way too much.

break it down into smaller objects/functions which are tailored to certain instance variables, features, or categories. (repeat as necessary)

(also, those defines are evil)

Answer 7

Inheritance objects, or you you should try array also, depends on how you use switch

Answer 8

Besides creating an array or function pointers and jump tables, you can create a map of function pointers. For that, boost::assign::map_list_of is very useful.

Then you can use find method to get the required element. Throw an exception or assert if the element is missing from the map.