Thanks for bringing this up. There is no reason for modern languages that have proper constants (not preprocessor macros which happen to sometimes be used for them) to use this tedious style.

Constants are so innocent and useful. Why indirectly discourage their use by making their usage an eye-bleed?

What alternative would you suggest?

In C++ I do it Google style:

  static constexpr int kConstantName = 42;

This is the old Mac style too. Might just be my upbringing but I prefer it.

What's the point of the `k` prefix?

k for konstant

Yes, that's what it stands for. What's the point of using any prefix at all?

So you don’t have to wonder if it’s a variable. Old Mac style uses prefixes: kConstant, gGlobalVar, TType, mMemberVar. Remember this was when all coding was done in black and white in a plain text editor.

Hungarian notation

Hungarian notation is for being more specific than the type system allows.

When the type is already "constexpr int", that k isn't helping.

IMHO that’s much uglier than using caps.

Sometimes when I use C++, I will namespace them however:

    namespace constants {
        static constexpr int name = 42;
    }
    …
    int x = constants::name;

The exact name of the namespace would depend on the use and could be something more descriptive.

Writing in a normal way in snake case or camel case or whatever the convention is.

Just use the same style as for variables. What's the point of the distinction? Maybe you'll want to change a constant into a variable later.

Interesting take, but good luck with this fight against all caps (snake case) constants, at this point it's almost a consensus, a shared culture element, a deeply ingrained habit that the vast majority of developers have and recognize.

Changing this would be a huge undertake I'd be afraid of engaging, if I cared that much.

Indeed, these are less readable and harder to type for no benefit

I do it mainly as a form of namespacing and aid in readability.

  do_thing(foo); // foo is variable

  do_thing(FOO); // FOO is constant (i.e this call should always do the same thing)

  foo = FOO; // I wanna name a variable the same as a constant

Same, but maybe alternatively I'd accept:

    do_thing(Constants.foo)

as equally clear...

The case of what is a constant, and whether or not it even really is, is not always clear in C. As an embedded developer (almost always on bare metal), variables declared with the const modifier are usually (but not always, it depends on the linker script) placed in read only memory. For those kind of variables (read only ones, they're not really constants as in C++ constexpr) I don't use all caps. But for preprocessor macros, always. Even "#define MY_CONSTANT 10" is a macro, and not a constant or a variable. And it should be treated with caution, because it is dangerous (inexperienced programmers might change it to #define MY_CONST 2 * OTHER_CONSTANT, which opens up a can of worms).

It's the reason Rust makes us use an exclamation mark with macro calls: beware! magic! here!

I like this as a convention, but not necessarily as a grammar rule. Printing values is common enough that it shouldn't require shouting for constant attention, simple code shouldn't trigger sensory overload.

I do think that the default convention of SHOUT_CASE for constants in Rust is too in-your-face given that there's nothing about Rust constants that would particularly require them to stand out. I might have gone with CamelCase given that some things in Rust already straddle the "types are CamelCase, terms are snake_case" delineation (enum variants, even data-less ones, are CamelCase, as well as the implicitly defined constant `Foo` for any unit struct `Foo`).

There is some gotcha: they're copied on use, which means you could end up with more than one copy in your binary (unlikely with an optimizing compiler), or, worse, that if you have interior mutability in them it just won't work.

SHOUT_CASE is truly the inferior way to refer to SCREAMING_SNAKE_CASE

nah, sorry, I'm going to keep using ALL_CAPS_CONSTANTS (and enum members, because they're also constants). I like having constants be visually distinct from the rest of my code.

Yeah, I don't see the problem. I believe this is default for pylint, and I see no issue with convention.