Header include order

From: Derrick Coetzee (dcnews_at_moonflare.com)
Date: 11/19/03 

Date: Tue, 18 Nov 2003 21:52:55 -0500

It seems like, in every C source file I've ever seen, there has been a
very definite include order, as follows:

- include system headers
- include application headers
- include the header associated with this source file

For example, in a file hello.c:

#include <stdio.h>
#include "utils.h"
#include "hello.h"

(Incidentally I think that a source file which doesn't include the header
 file which exports its symbols is _very_ bad, as this is a good way to
 check for inconsistencies for free.)

I would argue that the standard order of header including is wrong,
and that the correct order is the reverse. Consider this scenario:

hello.c:
#include <stdlib.h>
#include "hello.h"

hello.h:
struct blah {
    size_t size;
};

hello2.c
#include "hello.h"

Inexplicably (from the perspective of the person doing the including)
the file hello.h will cause compiler errors in hello2.c but not in hello.c.
If hello.c were written first, and then the include file used elsewhere,
the error would appear to be "new", and not be caught by those who wrote
hello.c, implementing the functionality exported by hello.h.

If this include order is used, this problem is averted:

- include the header associated with this source file
- include application headers
- include system headers

This is good for two reasons:
1. All headers must now include any system headers they need, and will
fail immediately if they don't.
2. Every header will be included in at least ONE source file before
anything else (the source file associated with that header), allowing
any intra-application dependencies to be caught.

Does anyone have a reasonable justification for the standard include
order that I haven't thought of? Thanks. 

-- 
Derrick Coetzee

Relevant Pages

  • Re: #include question
    ... > (translation units as I found them called in Bjarne Stroustrup's book). ... > I know about multiple inclusion guards, ... Correctly written headers, which includes standard ones and should ... classes and structs do nothing until a source file instantiates them ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Header include order
    ... >- include system headers ... >- include application headers ... >(Incidentally I think that a source file which doesn't include the header ... inadvertently declare an identifier already declared in a system header. ...
    (comp.lang.c)
  • Re: Subroutine header
    ... I used to write headers like those, these days I lean more on my ... compilation and linking details. ... build for production release I (in line with site standards) strip out ... this unsuitable for source file headers anyway. ...
    (comp.lang.fortran)
  • Re: Larkin, Power BASIC cannot be THAT good:
    ... headers), and no platform-specific macros. ... one source file. ... doesn't have classes, Java doesn't have pointers, or half of C++'s OO ... So the only languages that allow 40-year old programs to be simply ...
    (sci.electronics.design)
  • Re: #include "string.h"
    ... since any program does use some standard headers anyway. ... if you put string.h into the folder next to the source file, ... more than what it's talked about in 7.1.2p1 (or the intent for it ...
    (comp.std.c)
Loading