Compile guards and imports

Is it possible to establish some sort of heirarchy for inheritance of headers? It would seem that it would be far more readable not to mention trackable if the importer did all guard checking at the file head. This would also make it easier to tell who defined what and where. I am not by any means saying "the way it is now" is wrong, just very difficult to track when you are not the author of the code at large. For the most part I am not interested in your implimentation, but rather in the finished product and how to use its various facets and not cause naming clashes. In my own code I am using the following file head title block just to keep things straight for myself and hopefully for anyone whom chooses to use anything I conjour up.

Author: Aaron J. Scott
Date: 1/29/2012
Objects Provided:
Structures Provided:

c or c++ are not the greatest languages for this. (If you want proper header/body (called package spec/package body) tracking, have a look at ada). However, that is not much help for you.

The standard way of getting over this partly is to make each header included only once:

#ifndef Cmdtab_h
#define Cmdtab_h

header contents hereā€¦


Which means that you can include headers as needed if dependencies need to be satisfied.
As well as that, try and design your headers so that they only relate to one class or functional area. I find that looking at the compiler
listing or the completed output (pressing shift as you start the arduino build shows the generated files) and searching for occurrences of something also helps.

On linux, the following, executed in the arduino .libraries folder shows which header files are included for each file:

find . -print -exec grep -i '#include' {} \;

I suppose that then you could write something that resolved that into a tree.

I already know how to conditionally compile, my post is a plea for a development standard to be collaberatively implimented such that pertinent usage information is readily accessible in the file its self without need to decypher the entire code to acertain what is needed and what is provided.

In the past I've been on big software projects where such was the standard. Many thousand headers were written, documenting the dependencies. I never found it useful for maintenance because you could never be sure it was right. So I would not support such a thing.