4 ms·

really, avoid underscores altogether - they are very horrible. even people that know that there are exclusion rules for them don't really know what the rules ar

really, avoid underscores altogether - they are very horrible. even people that know that there are exclusion rules for them don't really know what the rules are. and if you get things wrong, the error messages your compiler gives you will be incomprehensible. so, just don't use them - why would you?

cesaref 4y ago
I've never seen leading underscores in classes. I've seen trailing underscores, and the old m_ prefix, but never a plain _. I was surprised by C++11 having additional prefixes it has reserved. I'm now also wondering whether there is a clang/gcc option to warn about such things, as although I know we don't currently have any issues in our code base (as in, it compiles and works) I don't really want to publish a public API and have to revisit it because of such a conflict in C++29 or whatever
- zabzonk 4y ago
  some underscores have been reserved in certain situations in user code from ansi c and onwards - there is simply no need to use them. trailing underscores will work but why bother? they are difficult to read and difficult to type.
  - colanderman 4y ago
    Trailing underscores are my go to for resolving conflicts with keywords. It's a much more consistent and trivial to remember rule than random misspellings or synonyms of keywords (casts side-eye to `klazz`).
    - zabzonk 4y ago
      don't understand this at all - why would you want to use a keyword as a name, and the last bit of the comment makes no sense at all.
      - flohofwoe 4y ago
        If you're implementing some sort of persistency or reflection system in C++, 'Class* clazz' isn't all that unusual.
      - seritools 4y ago
        maybe you build a game and the character has a... class?
        zabzonk 4y ago
        what is so special about the underscore that makes it differentiable?
- ryanianian 4y ago
  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.

cesaref 4y ago

I've never seen leading underscores in classes. I've seen trailing underscores, and the old m_ prefix, but never a plain _. I was surprised by C++11 having additional prefixes it has reserved. I'm now also wondering whether there is a clang/gcc option to warn about such things, as although I know we don't currently have any issues in our code base (as in, it compiles and works) I don't really want to publish a public API and have to revisit it because of such a conflict in C++29 or whatever

zabzonk 4y ago
some underscores have been reserved in certain situations in user code from ansi c and onwards - there is simply no need to use them. trailing underscores will work but why bother? they are difficult to read and difficult to type.
- colanderman 4y ago
  Trailing underscores are my go to for resolving conflicts with keywords. It's a much more consistent and trivial to remember rule than random misspellings or synonyms of keywords (casts side-eye to `klazz`).
  - zabzonk 4y ago
    don't understand this at all - why would you want to use a keyword as a name, and the last bit of the comment makes no sense at all.
    - flohofwoe 4y ago
      If you're implementing some sort of persistency or reflection system in C++, 'Class* clazz' isn't all that unusual.
    - seritools 4y ago
      maybe you build a game and the character has a... class?
      - zabzonk 4y ago
        what is so special about the underscore that makes it differentiable?
ryanianian 4y ago
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.