I think we should use the kCapWords naming scheme for global
const/constexpr values and for bare (non-scoped) enum values. For
example:
enum MyEnum {
kMyEnum_Value1,
kMyEnum_Value2,
};
but not
struct MyEnum {
enum type {
...
};
};
Does that seem like a reasonable distinction? I think the objective is
to be able to reason about constant values at the namespace level
On Fri, Jun 4, 2021 at 2:39 PM Micah Kornfield <emkornfi...@gmail.com> wrote:
>
> I would prefer kCamelCaps to be inline with the style guide (unless we are
> too far down a different path).
>
> On Fri, Jun 4, 2021 at 12:37 PM Antoine Pitrou <anto...@python.org> wrote:
>
> >
> > Le 04/06/2021 à 21:34, Weston Pace a écrit :
> > > The C++ code base currently has a mix of ALL_CAPS (e.g.
> > > arrow::ValueDescr::Shape, seems to be favored in arrow::compute::),
> > > CapWords (e.g. arrow::StatusCode), and kCapWords (e.g.
> > > arrow::DecimalStatus, not common in arrow:: but used in gandiva:: and
> > > technically what the Google style guide recommends[1]).
> > >
> > > I don't know that it is worth fixing any existing code but perhaps we
> > > should be consistent going forwards? In a recent PR of mine Antoine
> > > pointed out that ALL_CAPS can clash with macro names. That seems
> > > reasonable so my preference would be AllCaps.
> >
> > I'm in favor of CamelCaps as well.
> >
> > Regards
> >
> > Antoine.
> >
