> "treat foo.hpp the same way as other project headers". +1 This one may more easily to follow.
> 1) If you rely on symbols from bar.h, don't count on the fact that you > included foo.h which (currently) includes bar.h: include bar.h yourself, > 2) unless foo.h explicitly demonstrates its intent to provide you the symbols of bar.h. > 3) However, any includes present in the related header do not need to be > included again in the related cc (i.e., foo.cc can rely on foo.h's includes). I think most contributors have followed this for a long time? +1 for "clarify this in the Mesos style guide" On Wed, Dec 14, 2016 at 10:29 AM, Yan Xu <xuj...@apple.com> wrote: > Another related practice we should standardize is that, Google style guide > suggests here > <https://google.github.io/styleguide/cppguide.html# > Names_and_Order_of_Includes> > : > > 1) If you rely on symbols from bar.h, don't count on the fact that you > included foo.h which (currently) includes bar.h: include bar.h yourself, > 2) unless foo.h explicitly demonstrates its intent to provide you the > symbols of bar.h. > 3) However, any includes present in the related header do not need to be > included again in the related cc (i.e., foo.cc can rely on foo.h's > includes). > > We obviously follow 1) but AFAIK we don't follow 2) and 3), instead we have > been doing "include everything needed yourself, no exceptions". > > It would be great to clarify this in the Mesos style guide as well. > > --- > @xujyan <https://twitter.com/xujyan> > > On Wed, Dec 14, 2016 at 10:14 AM, Yan Xu <xuj...@apple.com> wrote: > > > 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/meso > > s/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". > > > > Since this rule has been introduced to the Mesos style guide I haven't > > seen much adoption. Most committers still observe the "old" rule when > > creating new files and have been instructing contributors to do the same. > > > > Given the current status I'd suggest we revert the style guide on this? > > It's only adding confusion and I don't see the need to do a sweeping > change > > to the codebase to comply with the new rule. > > > > Thoughts? > > > > Yan > > > -- Best Regards, Haosdent Huang