We're talking about new enums here, which should always be scoped enums,
i.e.:
enum class MyEnum { <some enum values> };
Le 04/06/2021 à 21:41, Wes McKinney a écrit :
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.
