I’m pretty sure developer notes were intended to say constants should be upper case and variables should be lower case, but right now they are ambiguous about whether to write:
0extern const int SYMBOL;
or:
0extern const int g_symbol;
First convention above is better than the second convention because it tells you without having to look anything up that the value of SYMBOL won’t change at runtime. Also I haven’t seen other c++ projects using the second convention.
I'm pretty sure developer notes were intended to say constants should be upper
case and variables should be lower case, but right now they are ambiguous about
whether to write:
```c++
// foo.h
extern const int SYMBOL;
// foo.cpp
const int SYMBOL = 1;
```
or:
```c++
// foo.h
extern const int g_symbol;
// foo.cpp
const int g_symbol = 1;
```
First convention above is better than the second convention because it tells
you without having to look anything up that the value of `SYMBOL` will never
change at runtime. Also I've never seen any c++ project anywhere using the
second convention
const int ... = 1; not a compile time constant?
Why is
const int ... = 1;not a compile time constant?
Can you give a more specific example? In the example from the PR description, the compiler does not know what the value of SYMBOL is when you include foo.h and use SYMBOL in compiled code, so it is misleading or at least a stretch to call SYMBOL a “compile time constant”. In this example, SYMBOL is just const in the sense that it can’t be modified after it is initialized and its value does not change at runtime.
82@@ -83,7 +83,7 @@ code.
83 separate words (snake_case).
84 - Class member variables have a `m_` prefix.
85 - Global variables have a `g_` prefix.
86- - Compile-time constant names are all uppercase, and use `_` to separate words.
87+ - Constant names are all uppercase, and use `_` to separate words.
There’s a name for that :)
- Constant names are written in screaming snake case (e.g. all uppercase and using _ to separate words).
or just
- Constants are written in SCREAMING_SNAKE_CASE.
const auto CURRENT_TIME = GetTime<std::chrono::seconds>();
const auto int BLA = ComplexFunction();, that’s a constant variable, but it’s not a compile-time nor link-time constant (neither compiler or linker knows its value).
I know, and my point is that these (not a compile-time nor link-time constant) haven’t been UPPER_CASED in the past and that this pull is changing the rule here.
Just asking to clarify.
re: #18568 (review)
- Constants are written in SCREAMING_SNAKE_CASE.
Informative, but I’d rather keep this PR minimal and not change extra things
In the example from the PR description, the compiler does not know what the value of SYMBOL is when you include foo.h and use SYMBOL in compiled code, so it is misleading or at least a stretch to call SYMBOL a “compile time constant”
While to compiler doesn’t know its value, it does know that it is a constant, right? Maybe I’ve been using “compile time constant” interchangeably with “link time constant”.
Updated 05f9770c1fa64bd9730cd6e18ec333e0801c00d6 -> 58ff41e2eca5250d88ddbc11db751146369a32b4 (pr/capconst.1 -> pr/capconst.2, compare) to not imply local constants need to be capitalized.
I’m assuming that in some cases it makes sense to capitalize local constants, and in other cases it doesn’t, and it isn’t important to have a rule about it.
82@@ -83,7 +83,7 @@ code.
83 separate words (snake_case).
84 - Class member variables have a `m_` prefix.
85 - Global variables have a `g_` prefix.
86- - Compile-time constant names are all uppercase, and use `_` to separate words.
87+ - Global constant names are all uppercase, and use `_` to separate words.
0 - Global or compile-time constant names are all uppercase, and use `_` to separate words.
Since there could be non-global-scope compile-time constants, which should be UPPER_CASE?
I wonder the same. Class-scope constants should be the same, right? Even function-level constants would be better off in caps, _ separated imo. Do we have any notable exceptions here?
Edit: I think the exception is function arguments and things that aren’t really constants but marked const to enforce that they shouldn’t be changed. So the “compile-time” makes a lot of sense.
compile-time constants and the exclusion of run-time constants
I second the extra specification of
compile-timeconstants and the exclusion ofrun-timeconstants
This PR is trying to drop the phrase “compile-time” because it doesn’t have an obvious and clear meaning (see discussion in opening comments above), and because being “compile-time” seems less relevant to how a variable should be used or named compared to other attributes like mutability, scope, and lifetime. Also, I don’t think in this document it is worth trying to be very technical or make detailed rules about how everything needs to be named. For local variables, it seems fine to just let developers have freedom to emphasize constness with caps where it seems better. Global variables are different because global variables are declared and accessed in different places, often far away, and if you are using one you almost always need to be aware if it has a constant value or if the value can change. Whether the value is initially evaluated at preprocessing time, compile time, link time, or perhaps early init can be interesting to know, but probably less relevant than knowing whether the value changes. A capitalized name is a good way to indicate that the value will not change.
Re: class constants, if it would help I could replace “global constants” with “global constants and other constants with static duration including namespaced and class-scope constants” here. But I don’t think developer guidelines need to be so procedural or legalistic. I wouldn’t expect someone just reading the updated text to be confused by it, and I wouldn’t expect someone familiar with C++ to think of ::MY_CONSTANT, my_namespace::MY_CONSTANT, and MyClass::MY_CONSTANT much differently by default. Also, it seems fine to me if someone wants to use normal variable names for non-global constants. I think the benefit of using ALL_CAPS in a symbol name is to communicate the fact that the symbol’s value will not change. If a developer chooses to not indicate or emphasize constness in some symbol name, it doesn’t seem like a problem.
Maybe just remove “global” or is there a reason to imply function-scope constants should be lower snake case?
Removing “global” is really my preference, and “global” wasn’t part of the original push which just dropped the “compile-time” phrase: pr/capconst.1. I added “global” later in pr/capconst.2 to try to address a concern about the rule sounding too broad (actually from you).
I think I’ll switch back to the original push for now since it’s pretty clear “global” doesn’t help in the way I thought it might. Clarifying things is hard I guess. My goal is really just to drop the phrase “compile-time.”
compile-time constants in the changed line.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
No conflicts as of last run.
pr/capconst.2 -> pr/capconst.1, compare)
cr ACK 05f9770c1fa64bd9730cd6e18ec333e0801c00d6
Current wording seems ok and attempts to make it more clear will only raise more concerns. Also, there doesn’t seem too much disagreement in practice about this. The rules hare are more descriptive than prescriptive, so the exact wording shouldn’t matter too much when most are doing the right thing anyway.
