On Wed, Dec 14, 2016 at 3:15 PM, Benjamin Bannier <benjamin.bannier @mesosphere.io> wrote:
> 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/ How does putting your own header at the top (vs. ~the bottom) help ensure "a header file always includes all symbols it requires"? > > > 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-organiza > tion#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 > > > Yeah I have no issues with this practice. I am mainly commenting on the status quo: there's an entrenched practice and the effort to change it seemed to have gone no where. I don't personally like one approach better than the other so I'd like to hear the community thoughts (e.g., technical benefit) on this and hope we reach a consensus. Cheers, > > Benjamin
