4 ms·

Leading underscores help you disambiguate `_name` the field from `name` the member-function. Similar thing in Python. How else do you solve this without it bein

Leading underscores help you disambiguate `_name` the field from `name` the member-function. Similar thing in Python. How else do you solve this without it being even more confusing? Is `m_` really preferable? (Honest question.)

flohofwoe 4y ago
Some coding styles use capitalisation for this (e.g. member 'name' vs getter 'Name()') - personally I prefer snake_case myself though.
saurik 4y ago
As offered by the comment you responded to: trailing underscore. And yes: since leading underscore is reserved, and something needed to be reserved for reasonably-good reasons, m_ is preferable to _ if some reason you simply refuse to use a trailing modifier.
- Dylan16807 4y ago
  > if some reason you simply refuse to use a trailing modifier I'm not going to make a big deal about it, but it makes more sense to me to put the scope of a variable at the front. The front is where you put foo. and foo-> and foo[], after all.
- int_19h 4y ago
  Leading underscore is only reserved if the following letter is uppercase. And it's fairly common for C++ code to have coding style that mandates that fields start with a lowercase letter anyway.
dlivingston 4y ago
We use `m_` at work and I've come to really appreciate it. It makes reading code very easy - any variable you see prefixed with `m_` is a class member field. Anything else is either a function argument, a locally scoped variable, or has some other prefix (`k`, for example, referring to static constants). Since we read code far more than we write it, sprinkling little "usage hints" like this across symbol names removes a lot more cognitive overhead than I would have thought.
- alex_suzuki 4y ago
  I don‘t think that using m_ or s_ as prefixes is bad, but I think it should be the IDE‘s job to provide visual hints (color, bold, italic, etc.) with respect to the identifiers storage.

flohofwoe 4y ago

Some coding styles use capitalisation for this (e.g. member 'name' vs getter 'Name()') - personally I prefer snake_case myself though.

saurik 4y ago

As offered by the comment you responded to: trailing underscore. And yes: since leading underscore is reserved, and something needed to be reserved for reasonably-good reasons, m_ is preferable to _ if some reason you simply refuse to use a trailing modifier.

Dylan16807 4y ago
> if some reason you simply refuse to use a trailing modifier I'm not going to make a big deal about it, but it makes more sense to me to put the scope of a variable at the front. The front is where you put foo. and foo-> and foo[], after all.
int_19h 4y ago
Leading underscore is only reserved if the following letter is uppercase. And it's fairly common for C++ code to have coding style that mandates that fields start with a lowercase letter anyway.

dlivingston 4y ago

We use `m_` at work and I've come to really appreciate it. It makes reading code very easy - any variable you see prefixed with `m_` is a class member field. Anything else is either a function argument, a locally scoped variable, or has some other prefix (`k`, for example, referring to static constants). Since we read code far more than we write it, sprinkling little "usage hints" like this across symbol names removes a lot more cognitive overhead than I would have thought.

alex_suzuki 4y ago
I don‘t think that using m_ or s_ as prefixes is bad, but I think it should be the IDE‘s job to provide visual hints (color, bold, italic, etc.) with respect to the identifiers storage.