How to avoiding writing switch-case too long?

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?

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.

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.,

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.

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 :/

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)

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.

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

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

One way is to use Polymorphism:

Instead of putting a huge case statement inside of function foo and calling it with some parameter, use a virtual method instead. You would write a base class with a virtual method, and then write a derived class for every case statement you currently have. For every case statement you currently have you can override the base class virtual method.

So for instance, instead of calling ptr->foo(c), you would instead call ptr->foo(). That way the compiler and the virtual table will be doing your switching for you.