In this case I would not yet care too much about performance. Primary target should always be readability and maintainability of your code. At work, I have to deal with legacy code containing, in multiple places, switch statements and deeply nested if statements with in some cases more than 5000 LOC. This is a programmer's nightmare come true.
Write the simplest, most easily maintainable version you can think of (using a function pointer table or inheritance) and use that, until you have some evidence (i.e. after you have profiled your code) that this has a measurably bad impact on your program's overall performance.
Exactly the kind of situation I`m facing. My colleague thinks it`s super ugly too, and thinks the company we`ve inherited it from must have had some super eccentric coders. 300 line functions and 15000 line files. Crazy. It`s even worse when you have to insert #defines and #ifdefs in between it all to handle seperate formats.
Thanks for the advice, and good luck to you with your code too!
This kind of stuff is par for the course in old code bases. Stuff might have started out small, and then people keep on adding stuff through the years as requirements change, features are added, and bugs are fixed.
Everyone thinks the code sucks, including those who wrote it, but they find comfort in convinving themselves that they "will refactor in the future". The truth is that that day will probably never come.
The upside is that this is all manageable with a good IDE that has nice code browsing features, code folding, etc.
The best advice I can give, is just leave it alone and learn to deal with it. If the product is worth anything, there should quite frankly be better things to do than to than to restructure IF-statements.
If you want to rewrite it, you should be able to demonstrate (with cold hard numbers) that it will in fact save time or money to rewrite it. Otherwise it's just programmer masturbation.
