>The rule to never include anything from a header is just the ultimate cleanup. What? No the two have nothing to do with one another. The clean up in the Linu

>The rule to never include anything from a header is just the ultimate cleanup. What? No the two have nothing to do with one another. The clean up in the Linux kernel involves having more granular includes, that is breaking up very large header files on the order of 10s of thousands of lines of code that often include unrelated or independent declarations, down into smaller header files that are on the order of 100-1000 lines of code and whose declarations are tightly coupled. I don't think many people would argue against breaking down large catch-all header files into smaller independent header files so that a consumer only needs to include what they need instead of having to include everything and the kitchen sink. >Note in particular that sched.h includes, directly or indirectly, 324 _unique_ header files. Header guards are not going to help you here... Of course not, and no one is claiming it will. It's also not going to help you if you decide to move all of those 324 unique header files into your .c file which is all this article is suggesting you do. What will help you is to refactor your dependencies so that you don't need to include 324 header files to begin with and instead can reduce your includes down to some minimal set. Once you've broken your dependencies down to a minimal set of headers, it won't matter whether you include that minimal set in a .c file or a .h file, what matters is that you've reorganized your dependencies to avoid having a bunch of declarations that are independent of one another. Ultimately you're conflating two very different concepts under the vague term "cleanup". Having granular header files is something many people would agree makes compile times faster and also just improves overall software quality, by all means do it. Moving all your includes from .h into .c is just some kind superficial cargo-cult programming and will have no material impact on compile times or quality.