Hi Yan, I don’t feel too strongly about most of our style rules regarding include ordering since they are just about style.
> For a cpp file foo.cpp, our style guide instructs folks to put the header > foo.hpp at the top of the include list: > https://github.com/apache/mesos/blob/master/docs/c%2B%2B-style-guide.md#order-of-includes > > This is consistent with Google style guide but in reality most of the our > files follow the rule of "treat foo.hpp the same way as other project > headers”. Among all our style rules regarding includes, this one actually does have a solid technical justification: It helps ensure that a header file always includes all symbols it requires (OK, possibly via discouraged transitive includes in the header itself). Not strictly following this rule has lead to broken header files making their way into the code base (both in the case of internal and public headers), see e.g., https://reviews.apache.org/r/54083/ https://reviews.apache.org/r/54084/ https://reviews.apache.org/r/54083/ I’d rather have us follow a style that performs some automagic checking of header completeness than rely on humans to catch all issues. Note that including `foo.hpp` first in `foo.cpp` is common practice, and I expect following this rule would lead to _less friction_ for newcomers to the Mesos code base, see e.g., (no particular order) http://llvm.org/docs/CodingStandards.html#include-style https://github.com/bloomberg/bde/wiki/physical-code-organization#component-design-rules https://webkit.org/code-style-guidelines/#include-statements https://github.com/facebook/hhvm/blob/master/hphp/doc/coding-conventions.md#what-to-include https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes Cheers, Benjamin
