I have been reading the many comments in this thread with some interest. Reading through your responses, I have come up with this summary of motivations for using this approach (these are my paraphrasings, often not quotes of the originals): + no lint warnings about repeated headers + no need for include guards + doxygen dependency graph much simpler + no cycles in include graph + removing unneeded includes is easier + simpler compiler diagnostics + easier to generate dependency makefile + improved identifiability of refactoring opportunities + ... and of interface accumulation [not sure what this means] + ... and of code collecting fat + constant reminders of all dependencies of each .c file Some questions: 1. Is this an accurate summary? 2. Has anything been left out (ie, is there any other positive you would add to the list)? 3. Would you mind listing these from most important to least important, and giving some indication of relative weight for each item? Yes, a topological sort. The topological sort is the easy part - the harder part is identifying what the first-level dependencies are. I may have some suggestions here, but first I would like to read through responses to the questions asked above, to make sure I'm going in a good direction.