Concept ACK. I guess it should be clear from the context that those are compile-time constants. Also, IIRC it is not possible to name a enum value ERROR, because this conflicts with some windows macro in our cross build. Error might work.

Concept ACK.

Mildly disagree with this change. I think it's nice to be able to declare variables that change at runtime as variable, and declare variables that don't change as CONSTANT, and just use the choice to try to make code more understandable. It's possible a constant could conflict with a preprocessor macro, though, and this could be bad. I don't check for preprocessor macros under my bed every night, and I'm not too scared of them, but maybe I should be! So ignore this feedback if this seems like the clear way to go.

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

ACK if this better matches what is in actual use in the project.

"clashes with macros" wouldn't be so much of an issue of C++ namespaced the things, but it doesn't, and as @ryanofsky already jokes they can just pop up from the kernel headers or libc headers out of nothing.

Checked the books/literature (Stroustrup, Meyers, Lippman, Moo, etc.) and they mostly use lowercase_underscore (snake_case) with a couple of the C++98 era ones using PascalCase (UpperCamelCase).

The Google style guide (https://google.github.io/styleguide/cppguide.html#Enumerator_Names) is a bit different but "use kEnumName not ENUM_NAME" for new code since 2009 for the same reasons.

Currently in this project it seems to be mostly ALL_CAPS, or in newer code lowercase (in src/bench/nanobench.h) or PascalCase (git grep -A5 "enum class ConnectionDirection").

I don't have a strong opinion (on my own I'd probably use lowercase_underscore (snake_case) with scoped enums as AFAICT it's widely used nowadays) but I think the important thing is to say which naming to use and to clarify if our choice is different from the CPP Core Guidelines so people aren't confused on which style to use.

I don't have a strong opinion (on my own I'd probably use lowercase_underscore (snake_case) with scoped enums as AFAICT it's widely used nowadays) but I think the important thing is to say which naming to use and to clarify if our choice is different from the CPP Core Guidelines so people aren't confused on which style to use.

Again just an opinion to throw in the mix, but I like CONSTANT<<3/2 to emphasize unchangedness of expressions when enums are used as collections of constants in bitwise or arithmetic code, and I like Confused NotConfused NotConfusedAndHungry ConfusedButSleepy for readability of english words in logical / event-handling code that more closely resembles natural language. I would not want to codify this and think it's fine to have guidelines that say there is no rule, and please do what seems appropriate.

guidelines that say there is no rule, and please do what seems appropriate.

Yes, that could be a helpful clarification too.

If there is no rule, we shouldn't be mentioning it

Per the current doc, the general rule is we follow the CPP Core Guidelines, but our examples are contradictory to it (and perhaps to common usage). I found this confusing.

Re-pushed an update that combines @ryanofsky's suggestion, open to feedback.

Updated per @ryanofsky feedback (thanks!) and rebased for #18568.

cr ACK 77f37f5

Agree with @ryanofsky regarding:

[…] it seems nice to move closer to cpp core guidelines and link to them even if not adopting them wholly.