4

In the C++ Google Style Guide's section on headers, the first line says:

Use standard order for readability and to avoid hidden dependencies: Related header, C library, C++ library, other libraries' .h, your project's .h.

But that appears backwards to me because project's headers are likely to be dependent on system headers whereas system headers are obviously not likely to be dependent on project headers. Simplifying the example given in the guide, we get the following #include lines for X.cpp that is dependent on X.h, the standard header <vector> and another file in the project's codebase, A.h:

#include "X.h"

#include <vector>

#include "other/module/A.h"

If A.h is dependent on <vector>, the style's order hides the problem. If the headers were included in the order of most related to least related the problem would be exposed.

What am I missing? Perhaps the counter-argument is that this problem would be exposed when A.cpp gets compiled but that argument doesn't stand if there is no A.cpp to start with (i.e. A.h is header-only).

screwnut
  • 1,367
  • 7
  • 26
  • 2
    If the order of inclusions matters, you are doing something seriously wrong. – Henri Menke Apr 15 '17 at 00:28
  • If `A.h` depends on ``, why wouldn't it have a `#include ` line within the file? – MrEricSir Apr 15 '17 at 00:33
  • 2
    @HenriMenke @MrEricSir The point of this guideline is defensive coding and to uncover potential problem. To uncover that `A.h` is missing a header, you'd want include in the opposite order that the guideline dictates. I contend that the guideline has the right goal but the wrong solution. – screwnut Apr 15 '17 at 00:51
  • Everybody's style guide does. You can't have the meaning of system headers altered by project headers, or dependent on them in any way, but you can have project headsrs dependent on system headsrs. – user207421 Apr 15 '17 at 01:01

1 Answers1

1

It seems like quite some years have passed without an answer.

I noticed that I was in fact using the header include order dictated by Google Style Guide, without much reasoning behind it, as indeed none was given in the Names and Order of Includes section, unlike other sections. So from their goals I can only guess that was done for consistency, allowing for some automation as they said, as well as "Just pick one [rule] and stop worrying about it" so that people can stop arguing over rules.

Too bad, as it looks like the order and reasoning given by Nathan's answer in this question make much more sense today. Personally, I'd gradually switch to that style of includes.

Hopefully, the future improvements in managing dependencies in C++ code will make this situation better. Ideally, not having to worry about order you state dependencies in, at all, and having better time at detecting and removing obsolete includes, usings, imports etc.

S. Kalabukha
  • 58
  • 8
  • Thanks for taking the time to reply! :) Since I asked the question, nothing had swayed my opinion and I order them essentially like in that answer you refer to. – screwnut May 22 '20 at 12:32
  • You're welcome! What's funny is that I found your question when I had the same question myself. And then I had to take more time to research and kind of answer it myself :). Well, "that's Stack Overflow for you", I guess. – S. Kalabukha May 25 '20 at 08:16