Modular programming is great, and I consider it mandatory practice. That, however has NOTHING to do with global variables.

Huh? It has everything to do with global variables. Before we start one of these crazy debates, though, I think we're talking about three flavors of "global" here, and we may have a problem already because that isn't clear. To fix that problem, let me define some terms:

• Function Variable This is what I think people usually mean when they say "local varaible". Function variables are defined within a function and are not visible outside that function. They're super.
• Module Variable This is one that's defined at file scope (outside of any function) and is therefore visible to all the functions within the same C source file (module). However, unless it's also declared in an (evil) extern statement somewhere, it's not visible to other modules.
• Global Variable This is one that's defined at file scope and declared in an (evil) extern statement so that it is visible outside the module in which it's defined.

Now, with those definitions in place, let us proceed with the crazy debate!

Russ, you are evidently a member of the "global variables are evil" society.

A card-carrying member, yes. But I am also a member of the "module variables are okay sometimes" society.

In your example above, why slow everything down just to have a "get a character from input" because "global variables are evil". It is much more effective to direct the data to where you need it.

I tried to explain why in my first post, but Russell Bull said it better. The point is to make each module as independent as it can be. Module independence (or "loose coupling", as Russell called it) is desirable for lots of reasons, including these:

• If a module behaves badly, you have a really good chance that the bug is actually in that module and you don't have to go searching through all your other modules to find it.
• If you keep each module's internal workings secret from all the others, you don't have to worry that changes in the bowels of one module will break code in some other module.
• If you do a good job of designing your modules (and also get lucky just a little bit), you will be able to reuse them over and over without a bunch of tweaking.
• If you do a good job of designing your modules, your code will be easier to read and understand.

As far as "slowing everything down", sure, there's going to be some performance overhead. When it matters, then you have to "break the rules" (Russell again) and do what you gotta do. When performance is not an issue, however, it's way more important to worry about building programs that you can debug and maintain than it is to fret over a few inconsequential machine cycles. This is basically the same arugument that we all had ten or twenty years ago when it first made sense to move from assembler to a high level language. You pay a little in performance to make your programs readable and maintainable, and it's worth the price 99% of the time.

Local variables are wonderful IF they are truly local. Restructuring everything just to keep some variables local is sheer folly. I know the speedkiller of function calls with 17 parametres is supposed to be 'elegant' and 'true C'. Bullshit!

I agree with this if your use of "local variables" matches my definition above. The refactoring I favor is that which changes "global variables" into "module variables".

Of course since "C is self-documenting" your variable names are probably i, j and k which, indeed does make global variables dangerous. However the risk of having a variable such as GBiicInputReady misused is ZERO unless a complete idiot is thinking it is 'useable' for something else.

Your notion of "misuse" is too narrow. Good variable names are important, for sure. But good naming alone will not reduce to ZERO the risk of misusing global variables, even among us idiots who are not yet complete. As an example, suppose that Module A defines a (global) variable 'GBiicInputReady', and that it is referenced for one reason or another by three other modules. Now suppose that Programmer E makes a change to Module A that accidentally corrupts 'GBiicInputReady'. Suddenly he has code spread across four modules acting weird instead of just one. It's not pretty, and it's not necessary.

The "global variables are evil" MAY have a place in PC programming, but the '51 ain't no PC.

"The '51 ain't no PC". That's a true statement. It's also a great little catch phrase when some duDe asks u 4 help coz he can't find a VB.Net compiler for his SiLabs eval board. But it doesn't apply here. Good programming practice is platform independent. Global variables are evil because they compromise your (mandatory) efforts toward modular programming. Avoid them when you can.

-- Russ