11

Are there any technical reasons for the use of the underscore in names like (for example) scoped_lock in the Boost library? Why not call it `ScopedLock?

Please note I am not asking about stylistic reasons.

Improve this question
15
  • 5
    Neil, you didn't already know that? You given some pretty awesome answers in the past, did someone hack your account ? ;) Commented Apr 20, 2010 at 20:10
  • 1
    Most languages historically adopt one or another naming convention, but in about all language I know it is a purely aestethic decision. The only exception AFAIR is Java an the like with horrible "property" name -> getter/setter name transformation. Commented Apr 20, 2010 at 20:15
  • 2
    Because it looks like a space (provides more visual spacing), but spaces aren't valid characters for identifiers. Commented Apr 20, 2010 at 20:21
  • 2
    I'd_rather_have_sentences_written_like_this, ThenHaveItAllSquishedTogetherLikeThis; the former is easier to read. (Both are easy, of course. But the former breaks words up, which is the way language works, rather then shove them all together.) Commented Apr 20, 2010 at 20:45
  • 2
    How could you believe that there is a technical reason behind a naming convention? Commented Apr 21, 2010 at 1:57

17 Answers 17

Reset to default
21

From the Boost Library Requirements and Guidelines,

Given the intent to propose portions of boost for the next revision of the C++ standard library, boost decided to follow the standard library's conventions.

Improve this answer
Sign up to request clarification or add additional context in comments.

9 Comments

@Dennis Zickefoose: Matching the consistency of a library so you can merge into it painlessly sounds pretty technical to me. A stylistic reason would be because they thought the standard library's method looked nice.
The C++0x standard library has a ton of functions and classes with underscores (I'm sure C++03 does too, but it doesn't have the handy "Index of Library Names" that the C++0x FCD has, so it's not quite so obvious).
The current standard library has all its symbols in lowercase, that's a strict rule. If your symbol is entirely in one case, any non trivial combination of words will be very difficult to read and you'll need the underscores to make it readable. The fact that underscores are rarely used is merely because most of the symbols are single words or unambiguous word pairs. If you can find those words for what you want to represent, fine, but the library is growing in complexity and such luck will become more rare in the future.
@Fabio: All its symbols except std::ios_base::Init (and maybe others). :-P
@Neil const_iterator, reverse_iterator, for_each, etc.
|
13

There is no technical reason. If you ignore the stylistic reason, you could write scopedlock, istreamiterator and the-like too.

Improve this answer

3 Comments

I was about to write the same.
For anyone getting upset about my answer: I interpret him as asking about underscore ultimately - not merely in the boost library. So boost follows the C++ library - but which style does the C++ library follow? Certainly not the C library, which uses the strtol style (as opposed to str_to_l or strToL style). Ultimately, it's all about style.
@litb: I responded in a similar fashion
8

Readability if you can call that technical... spaces are usually forbidden and underscore is the nearest match. Camel case is horrible to read (an often is reserved for classes as a convention)..

Improve this answer

4 Comments

you are the first person I have ever encountered who says camel case is hard to read. I personally consider using underscores rather jarring. I much prefer camel case.
Also, PascalCase is usually reserved for classes, camelCase is usually for variables.
@Blorgbeard: I use the term camelCase to speak of both camelCase and PascalCase. But of course you are right the most used convention for classes is to begin with Uppercased letter.
@rmeador: I believe your are from majority, but I'm far from being the only one that find CamelCase hard to read. The best illustration i've seen on the subject is the following : i_find_it_is_much_easier_to_read_something_in_underscores_than_in_camel_case ButThenAgainThatMightJustBeMe,YouShouldAllLetMeKnowWhatYouThink.
5

Underscores improve the interface with human neural hardware by creating more space between separate words.

I used to prefer camelcase when I was little, and had a small monitor and small hands. I've mostly come around, though.

Improve this answer

Comments

3

Subjectively I find underscores a bit of overkill in code. There is enough abuse of non-alphanumeric symbols in code as is, I think introducing them into identifiers is a bit over the top. Just off the top of my head consider this excerpt from a boost template error:

Derived=boost::transform_iterator<std::binder1st<std::multiplies<size_t>>,boost::counting_iterator<size_t>>, Base=boost::counting_iterator<size_t>, Value=boost::detail::transform_iterator_base<std::binder1st<std::multiplies<size_t>>,boost::counting_iterator<size_t>,boost::use_default,boost::use_default>::cv_value_type, Traversal=boost::use_default, Reference=boost::detail::transform_iterator_base<std::binder1st<std::multiplies<size_t>>,boost::counting_iterator<size_t>,boost::use_default,boost::use_default>::reference, Difference=boost::use_default

versus the following that has been converted to Pascal case (I prefer this method):

Derived=boost::TransformIterator<std::Binder1st<std::Multiplies<SizeT>>,boost::CountingIterator<SizeT>>, Base=boost::CountingIterator<SizeT>, Value=boost::detail::TransformIteratorBase<std::Binder1st<std::Multiplies<SizeT>>,boost::CountingIterator<SizeT>,boost::UseDefault,boost::UseDefault>::CVValueType, Traversal=boost::UseDefault, Reference=boost::detail::TransformIteratorBase<std::Binder1st<std::Multiplies<SizeT>>,boost::CountingIterator<SizeT>,boost::UseDefault,boost::UseDefault>::Reference, Difference=boost::UseDefault

I can see the advantage of underscores when taken in isolation but with all our other symbols I think we should focus on making programs that read closer to english and not underscore-ese.

Improve this answer

1 Comment

I totally agree with you. I absolutely hate underscores in code. I know it's just stylistic preference and that there are people who hate CamelCase. I've actually written a header called stlpretty.h that just has a bunch of #defines in it to convert the underscores to CamelCase. It's silly and people here will probably flame me, but I read and write CamelCase so much faster. There's probably some miswiring in my brain, but underscores hurt me, and slow me down.
1

There's no technical reason, but there's a reason. You've got to agree with me that it's much easier to read scoped_lock then scopedlock, but scopedLock would make it too. Yet, with underscore is easier to read, IMHO.

But a well-written code is a legible code. It's part of knowing to program well.

Improve this answer

18 Comments

Your opinion that scoped_lock is easier, harder or the same to read as scopedLock is just that -- your opinion.
It's not really an opinion. Spaced out words are easier to read. That's why we use them in regular writing.
@John: there's more to it than simple opinion -- there are empirical studies. For example, see: Fillers and spaces in text: The importance of word recognition during reading. by J. Epelboim, J. Booth, R. Ashkenazy, and A. Taleghani R. steinmans (Vision Research, 37(20), 1997). They compared reading with spaces between words removed (producing something similar to camelcasing) and with shaded boxes inserted between the words (producing something similar to underscores). Removing spaces slowed reading and comprehension, but inserting shaded boxes did not.
@Jerry But did they try it with underscores? Not clear from your description/
@GMan: in some (e.g., Asian) languages spaces are not normally used though. In other (e.g., Germanic) languages, you can pretty much put together long compound words as you see fit. That's probably source of the concept of compound words in English, but here it's limited to predefined words, not created at will as in German.
|
1

There's no technical reason.

Variable names in C++ must only

  • Start with a letter or underscore
  • Contain only number, letters (capitalized or not) and underscores

Using this_way or ThisWay is just a matter of style.

Improve this answer

8 Comments

they can also start with underscores
Technically you can still use them, i.e. it is not a compilation error. But they could be used by some compiler, so you could in principle run into a portability problem with those.
Names and other identifiers can also start with a universal-character-name. For example, you can use int \u0391\u03A9 to indicate that your variable is the end-all-be-all of variables.
Don't forget dollar signs! Ok, yeah, you can forget them.
@doublep: Using them results in undefined behavior. Even suggesting that you can maybe use them is foolish. Don't do it, period. Then, you'll never have problems.
|
1

The only technical reason is for readability because using CamelCase may cause the wrong interpretation, especially when referring to abbreviations in all caps. A GPS Socket would come out as GPSSocket. There are some better examples, but my mental block precludes me from writing them down. :-(

If you want to get technical, there is no reason since the underscore is a viable character for identifiers.

Improve this answer

Comments

1

Although technically speaking there is no difference there could be issues caused by environment. For instance, if you include windows.h you will not want to name any function TextOut even if that's what the function does. The reason is that this name will get replaced by the preprocessor due to the fact that TextOut is a macro in the win32 API. For this reason a project manager may wish to impose non-camel case as a standard.

So there can be technical reasons but there's no reason imposed by the language itself. It's not like Java (does it still do this?) where you are forced by the compiler to use camel case.

Improve this answer

4 Comments

TextOut is a function, not a macro - see msdn.microsoft.com/en-us/library/dd145133%28VS.85%29.aspx
@Neil: Unfortunately, despite what the documentation would have you believe, TextOut is a macro that expands to either TextOutA or TextOutW depending on whether the code is being compiled using Unicode or not. This is a trick that is pervasive throughout the Win32 API.
@Aeth @Noah Actually, I'm tempted to accept this, as the best technical reason. But to think that we must use lower case and underscores because Microsoft have pre-empted all other names is not only sad, but false.
@Neil - you must not make much use of the win32 API. I actually have an unfortunate real-world example to go by. In the past the manager of our team insisted on using the MS naming conventions. Now we're switching one of our products to unicode. There's this library we need to use that has things like "TextOut" as member functions but isn't unicode ready. We're now going to have to do a lot of extra work because attempting to use the headers of that lib in a unicode project results in linker errors (because all the names are changed).
0

There is no technical reason per se. But I do have a reason other than my glib "because they look kewl."

My reason is because I find it useful to distinguish member variables from non-member variables in a convenient way. In particular when I am transferring data from a local variable to a member variable, such as within a constructor. Cheap example:

class Socket { public: Socket(const sockaddr_in& group) : group_(group) { } private: sockaddr_in group_; };

If you ask my opinion, most variable naming schemes are terrible because there are too many rules and too many ways they break down. The classic example of a horrible naming scheme is Hungarian, but even from that I did take something useful: the m_ prefix for member variables came in handy at times. Not too often but often enough for me to borrow the idea if not the method.

Improve this answer

Comments

0

There is no technical reason. It is purely stylistic. To be specific, C++ views all symbols that begin with a letter, underscore, or dollar sign the same. The only difference is how they are declared. If you want, you can name your "thing" class as Thing, THING, thing, tHiNg, or even T_h_I_n_G_$ if you want... it won't make a difference to the compiler. However, it does make a difference to other human beings that will look at and use your code. And if you take this too far (such as the last couple of examples I listed), you might even find your life in danger at some point (an angry programmer can be a terrifying thing).

Improve this answer

11 Comments

Except that your second sentence is false. The C++ standard specifically mentions identifiers beginning with underscores as being reserved for implementation use depending on various things like scope and second character.
You cannot use $ in identifiers--whether it is at the beginning or anywhere else in the identifier.
Yes, the user is highly discouraged from using them, for this reason, but there's nothing stopping you from creating a variable name starting with an underscore, provided that identifier hasn't already been declared elsewhere.
@DoctorT: I agree that the acceptance of $ is widespread. The g++ 4.1.2 compiler that codepad uses rejects it, but that compiler curiously also rejects universal-character-names which the standard does allow.
@DoctorT: It's generally good practice to stick to the standard. That way, you won't be sideswiped by later changes in the compiler. There are rules on identifiers with beginning underscores, which I prefer to summarize as "Don't!". There is a rule against dollar signs in identifiers. Testing nonstandard extensions is usually a bad idea. If an extension is not in the standard, and not in the compiler documentation, don't use it.
|
0

There is no technical reason for or against except that which is imposed by the language, which in this case, does not exist.

Improve this answer

Comments

0

This reason skirts the edges of being stylistic, but since no one else has mentioned this so far, I'll simply add that in a case sensitive language like C++, underscores are more memorable than capitalization.

For example, sometimes you might see scopedLock instead of ScopedLock. If you never use caps, that's just one less thing to keep track of.

Improve this answer

Comments

0

Well, not the compilers, but prefast rulesets sometimes try to enforce naming conventions. To be frank, so many conventions are really confusing; escpecially when one needs to support old code as well as write new code in multiple languages.

Improve this answer

Comments

0

One technical reason I can think of (especially for member function names) is to allow duck-typing. For example, the following boost classes could be used (to some extent) where one expects an STL container:

  • boost::ptr_container and family
  • boost::multi_index containers
  • boost::array
  • boost::dynamic_bitset (in lieu of boost::bitset)
Improve this answer

Comments

0

IMHO, it is pretty reasonable to adopt the style of the Standard Library for the language you use. If it is Java, it is scopedLock, if it is C++ it is scoped_lock. If it is Lisp, it is scoped-lock.

Not that it really matters, anyway.

Improve this answer

Comments

0

When C was invented, it was used on Unix, and Unix was operated from terminals that resembled typewriters. Some terminals had both upper and lower case letters, but some terminals had only upper case. If you wanted to use a Unix system but all of the nice terminals were already occupied by your mean greedy selfish colleagues, you got stuck with an older terminal. This is the reason why, if you type your login name in all upper case characters, Unix assumes you don't have lower case. Each lower case letter gets displayed as the corresponding upper case letter, and each upper case letter gets displayed as an asterisk followed by itself.

Now imagine camel casing instead of underscores.

By the way C was based more or less loosely on PL/I. PL/I was punched into cards which originally didn't support lower case, and eventually could be hacked to support lower case but not in a puncher-friendly fashion. Furthermore it was usually printed by printers that didn't support lower case, though a few did. So lower case was out, camel case was out, and programmers were used to underscores. (Except for Cobol programmers, who were used to minus signs in the middle of identifiers meaning this-is-an-identifier not this minus is minus an minus identifier.)

Pascal was invented later, in an environment where lower case letters were more common but still not universal. Camel case became possible because Pascal was case insensitive. Camel case became popular because Pascal didn't allow underscores in identifiers.

So if you like camel case combined with case sensitivity, you're half-Pasced.

Improve this answer

Comments