>Simple rule: include files should never include include files. For small programs, that's a good rule* . For larger code bodies, it's counterproductive. If

>Simple rule: include files should never include include files. For small programs, that's a good rule* . For larger code bodies, it's counterproductive. If my module uses foo, there's no reason for my module to know that foo depends on bar. If the next version of foo drops its bar dependency and now uses baz which also requires fat, foo's clients shouldn't have to be rewritten. You can ameliorate the breakage sometimes by keeping dependencies out of header files (and that's generally a good idea), but sometimes you can't. My personal rule is exactly the opposite: every header should compile with no prerequisites. For that reason, the vast majority of my foo.h files are included as the very first line of foo.c. If foo.c doesn't compile, I know to fix foo.h. Pike's concern that lexical analysis is the most expensive compiler phase is way out of date. * In 1989, there were no large programs. (-: