IMO, serial ifs should be used if you want every condition to be checked. if/else/else ifs are used if you want to stop once one of the conditions is positive and don't need to assess any further conditions.

Global scope means any program/code can open your code and use/change the value stored in the variable---maybe even remove it! You can help protect the integrity of the data by using only it in the appropriate scope for which it is needed. Windows code uses global variables quite extensively, so it can be done with a fair amount of success and safety, but it isn't consider "proper" form when there are other, safer, options.

You can also use a switch case statement instead of multiple if / else if
Globals are to be avoided at all cost. They can get you in great trouble. In fact OO was partly invented to avoid globals!

so your saying that if you have data as globals another separate program is allowed to manipulate that data easier? I thought it didnt matter where it was in RAM?

No, that's not what's being said. Programs are in separate memory chunks. Only if you take special actions to allocate some shared memory will different programs have access to common data.

Global variables are visible to all functions in your program. Because all functions can change the global variable, there's always the danger/temptation for all function TO CHANGE the global variable. In anything beyond a trivial program, you quickly lose control over who should change the variable, under what conditions it should change. You also lose the ability to easily use any function in another program if some global variable must also be replicated.

A function should act like a "black box". You know what goes in (the input parameters) and you can see what comes out (the return value or any parameters passed by reference). What the function does inside itself is of no concern to any other function in your program. Global variables add an unknown factor to this clean input/output picture.

To say that global variables should be avoided "at all costs" is a bit extreme - as are almost all absolute statements. Sometimes there may be some variable which a large number of functions need access to, and some may change it, and all need to be able to know the current state of that. Perhaps some configuration state of the program. So sometimes, a global makes sense to use. When that is the case, DOCUMENT THE HECK out of it - state clearly what functions should be able to change it, under what circumstances.

Nice explanation vmanes.
Would not call that a global variabele in the sense that is meant here. This would typically be stored in a resource or config file.

Only if the behaviour sought is comparing an integral variable against a fixed set of values. It is not possible to use a switch statement with non-integral types, or have a case that is not a compile-time constant.
Like all dogmatic statements, this is correct sometimes and incorrect sometimes. Global variables are useful (without causing trouble) in some circumstances and not in others.
That's not true. It happens that a lot of well-designed OO designs or code will not use globals, but a lot of well-designed programs (OO or not) do not use globals. Eliminating globals, however, was not even a minor goal in creating the OO design or coding techniques.

What's dogmatic about the fact that globals are to be avoided at all cost? As I stated you can get in great trouble with them, indicating that this don't has to be so. Please use gobals at will if you like, there is no law against them! I like C# very much(among other laguages) simply for the fact that C# has no header files with possible globals, still I can do the same things with it as with C or C++.

Dogma (n) : A firmly held belief based on faith, and often stated as fact.

OK grumpier you win, but that doesn't mean I lost my faith in the fact that globals...