# How to avoid spaghetti code when I have a lot of conditions? [duplicate]

I have the following problem:

• An user can withdraw money from 2 payment systems (but the number of payment systems can change anytime in the future).
• If user has a trusted account on either of these payment systems, money is transfered automatically
• If user enters a new account then he needs to wait until the end of month to be able to transfer money to this account.

Suposse we have payment systems X and Y. There exist all the following information items:

• We can do auto withdraw X (1 - Yes/0 - No)- column 1.
• We can do auto withdraw Y (1 - Yes/0 - No) - column 2.
• We have deficit of X (1 - Yes/0 - No) - column 3.
• We have deficit of Y (1 - Yes/0 - No) - column 4.
• User has trusted account of X (1 - Yes/0 - No) - column 5.
• User has trusted account of Y (1 - Yes/0 - No) - column 6.
• User can auto-withdraw X (1 - Yes/0 - No) - column 7.
• User can auto-withdraw Y (1 - Yes/0 - No) - column 8.
• User can withdraw X in end of month (1 - Yes/0 - No) - column 9.
• User can withdraw Y in end of month (1 - Yes/0 - No) - column 10.

In table bellow I tried to show all use cases:

Column 1; Column 2; Column 3; Column 4; Column 5; Column 6; Column 7; Column 8; Column 9; Column 10

``````1; 1; 0; 0; 1; 1; 1; 1; 0; 0

1; 1; 1; 0; 1; 1; 0; 1; 1; 0

1; 1; 0; 1; 1; 1; 1; 0; 0; 1

1; 1; 1; 0; 1; 0; 1; 0; 0; 1

1; 1; 0; 1; 0; 1; 0; 1; 1; 0

1; 1; 1; 1; 1; 1; 0; 0; 1; 1

0; 0; 0; 0; 1; 1; 0; 0; 1; 1
``````

Please advise how can I avoid a lot of `if`s?

• Karnough maps – ratchet freak Nov 5 '14 at 16:45
• Lots of 'ifs' do not = spaghetti code – bowlturner Nov 5 '14 at 16:58
• Have you actually tried coding this? As @bowlturner mentioned, having many if-statements does automatically mean "spaghetti code!". If they are arranged logically, and nested ifs are refactored into other procedures, it might not be that bad. Maybe try it first to see... – FrustratedWithFormsDesigner Nov 5 '14 at 18:11
• I have an accepted answer to a similar question here: programmers.stackexchange.com/questions/205803/… – Tulains Córdova Nov 5 '14 at 18:25
• "Spaghetti code" means a tangle of control flow or state or dependencies, e.g. class A sets global X then calls B which sets Y which calls C which checks X and maybe sets Z and then calls back to class A... You just require a moderately complex boolean expression. – kevin cline Nov 5 '14 at 18:43

How a bout a rules mechanism? Define a class(or a struct or whatever) that defines a rule:

``````class Rule {
bool weCanDoAutoWithdrawX;
bool weCanDoAutoWithdrawY;
bool WeHaveDeficitOfX;
bool WeHaveDeficitOfY;
...
}
``````

Now, create a list of `Rule`s, and fill it with `Rule` objects that represent the rules you described in the question. When you want to check a transaction, go over that list and check if it matches the rule. If at least one rule does - approve the transaction.

If you are not familiar with OOP you can store the different sets of conditions as strings of concatenated 1s and 0s ("1100111100","1110110110", etc) stored in a string array. Then you can traverse that array. If at least one string matches the actual values - approve the transaction.

• A rules mechanism is often the first step down the road to the Inner Platform Effect. – whatsisname Nov 5 '14 at 20:25
• @whatsisname sounds plausible, I would caution anyone using this approach to make sure not to take the second step. – user22815 Nov 5 '14 at 20:55

As I don't see any language specified, use 'switch'. -Or if using C, you can make a function that handles each account type, then make a list of function pointers.

``````typedef void (*Account)(uint32_t aParameter);
static const Account[] = { mondoBurger, goodBurger };
``````

-If using C++, JavaScript or any other OOP language, you could make an object that handles each account type.

The bottom line is: You can use modular code. One "handler" (whether it be a function or an object) for an account. One "handler" for each action type that can be made.

Thus you just install the handlers in a list and hands the list to the processing function.