The only practical issue with "out of control" includes is still compilation time though, especially if modifying a single file causes many other files to rebui

The only practical issue with "out of control" includes is still compilation time though, especially if modifying a single file causes many other files to rebuild because they include it directly or indirectly. Beyond that I really don't care about it, I don't usually bother to micromanage my #includes, I don't really see the point. Beyond that I think that very complicated include graphs are usually a sign that there's an architectural problem with the application, forbidding includes within includes treats the symptom, not really the core of the issue. As a quick example of some code I wrote not long ago: I have a microcontroller communicating with an external chip over a serial link using a custom protocol. I have a "serial.h" file that describes the API to send and receive serial messages, then a "protocol.h" that implements the higher level protocol. protocol.h includes serial.h since it uses it as a lower layer, it's effectively a dependency. I don't really think it's a problem. So I'm not really sure that it makes a lot of sense to forbid includes within includes as a rule of thumb. I guess if I was to make a rule it would be "include trees are fine, include graphs are bad"? As in, there shouldn't be cycles in the include graph?