To be entirely honest, that sounds utterly horrible. It breaks all rules of modularisation and scope, and misuses C features. Your "Global" macro has different definitions in different files - never a good idea. C has an almost complete lack of proper modularisation features - if you want to write proper modular programs, you have to do it yourself.
The most common way to structure your files is one header file plus one source file equals one module, or is some variation on this theme. Each module exports an interface, consisting of functions, types, global variables, #defines, etc. Everything that is exported is in the header file, using "extern" declarations. The definitions are all in the source code file, along with non-exported data and functions (which should of preference be declared static, but most people are a bit sloppy about that). If you have a module called "timers", you might have a pair of files such as:
/* Timers.h */ #ifndef __timers_h__ #define __timers_h__
#include "common.h" extern volatile uint16 seconds; extern void initTimers(void); #endif
/* Timer.c */ #include "timers.h" volatile uint16 seconds;
static uint timerTicks; // Local data static void timerInterrupt(void) {... } // Local function
void initTimers(void) { ... }
There are a few things to note here. You need a "#ifndef ... #endif" pair to protect the header against multiple inclusion. The timers.c file includes the timers.h file - this allows the compiler to check for inconsistencies. You typically have a couple of stand-alone header files with common types or macros - but no "extern" data or functions without a corresponding source file to define them. There may also be stand-alone header files for libraries (either for pre-generated library files, or for separate directories of source files), and there will be one stand-alone source file containing your main() function.
Think of header files as declaring an interface, and source files as defining the implementation. That way you know what different bits of your program do, and you can find the bits you need, and you change only relevant bits of code. You can also re-use bits as necessary in different projects. Comments should, of course, match this separation - header file comments say what a function/variable does, and source file comments say how they do it (for source-local data and functions, they must say "what" as well as "how").