CODEWITHSUNDEEP
c++cheader-files
kvu787
kvu787

Reputation: 961

Understanding the "build break" rationale for Google's C++ Style Guide's guideline for #include order

Here is a section on #include's from Google's C++ style guide:

In dir/foo.cc or dir/foo_test.cc, whose main purpose is to implement or test the stuff in dir2/foo2.h, order your includes as follows:

dir2/foo2.h.
A blank line
C system files.
C++ system files.
A blank line
Other libraries' .h files.
Your project's .h files.

Note that any adjacent blank lines should be collapsed.

With the preferred ordering, if dir2/foo2.h omits any necessary includes, the build of dir/foo.cc or dir/foo_test.cc will break. Thus, this rule ensures that build breaks show up first for the people working on these files, not for innocent people in other packages.

I don't understand the last line:

Thus, this rule ensures that build breaks show up first for the people working on these files, not for innocent people in other packages.

Can someone explain how putting dir2/foo2.h first results in a "good" build break, and how putting dir2/foo2.h last results in a "bad" build break?

Upvotes: 10

Views: 1650

Answers (2)

Jaa-c
Jaa-c

Reputation: 5137

In dir2.h, you forget to include X.h. Then in current file you include:

X.h
dir2.h

This will compile fine. Then someone else includes dir2.h somewhere else and they end up with compilation error originating from dir2.h, even if they never changed anything in that file...

If you have the correct order, you should get the error first time you include dir2.h.

Upvotes: 15

nvoigt
nvoigt

Reputation: 77285

A "good" build break is when it breaks for the guy making the breaking changes. Because that guy can repair it. If that guy does not notice those breaking changes because the include files are sorted so it does compile for him by plain chance, then it will be released.

A "bad" build break is when the released version breaks the build of the users of that code.

Upvotes: 4

Related Questions