Time to impose some discipline on #include header ordering:
(1) We need to be absolutely certain everybody is seeing
the SAME #define settings from config.h and options.h
(so many of the my_foo.h depend on config.h settings
and yet config.h was being listed later. how did this happen?)
(2) It REALLY helps for documentation and code comprehension
to have .c files clearly point to the .h files that
export their interfaces (usually it's the like-named .h
but sometimes it is not and this can be confusing to
the newbie maintainer)
So... new rules:
For .h files:
config.h if referenced, goes FIRST.
options.h if referenced, goes SECOND.
For .c files the ordering of #includes shall be:
(1) The .h file(s) defining the exported interfaces
that this .c file is implementing
(typically this will be just one file, foo.h
if this is foo.c, but exceptions exist)
(2) config.h, then options.h, in a stanza by themselves
if referenced and not already included by (1)
For both .c and .h files we then have two more stanzas:
(3) system headers,
including the "my-foo.h" corrective headers.
(4) own headers, other than the ones that go in (1)
Except for special cases like net_proto.c and net_mplex.c
where the whole purpose of the file is to BE an #include festival,
there should be no further #includes after the initial block.
All includes should appear at the top of the file where we can see them.
... ok, I'm done.
