Hacker News Reader

Comment by zabzonk | Hacker News Reader

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?

View on HN

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

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.

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`).

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.

If you're implementing some sort of persistency or reflection system in C++, 'Class* clazz' isn't all that unusual.

maybe you build a game and the character has a... class?

what is so special about the underscore that makes it differentiable?

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.)

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

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.

> 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.

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.

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.

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.

Reply on news.ycombinator.com