Why does the STL/Boost C++ coding style differ so much from everyone elses?

I'm a fairly rookie C++ programmer, but in my limited experience with the language, most standard C++ style guidelines (e.g. Google C++ Style Guidelines) go against what is implemented in the stl and boost libraries.

For example, class names in the C++ standard library and Boost are always lower case, with underscores separating words (e.g. std::vector, boost::unordered_map, std::map::const_iterator), whereas most style guides I've seen for C++ tend towards a CamelCase style (e.g. TcpConnection or Int32).

The same applies to methods too. The standard library and Boost use the same style for methods and functions as they do for classes (e.g. std::map<>::get_equal("foo")), whereas most style guides advocate pascalCase or CamelCase.

If we contrast this with a language like Ruby, where most users will adhere to the conventions used in the core libraries, it seems odd that there'd be such a difference between the standard C++ libraries and everyone else's code.

Does anyone know why this is?

EDIT: Just to clarify, I'm talking simply about the superficial textual style (casing, use of underscores, etc) rather than actual implementation style.

underscores and lowercase was the style perferred by Bjarne Stroustrup in "The C++ Programming Language". If I recall correctly he had made a statement along the lines that underscores in names were to be preferred because it was more readable to an international community where english is not the primary language. I have no idea if his opinion is true or not, but I'm guessing that's the origin.

Here's a link to his FAQ where he discusses this very topic:

http://www.stroustrup.com/bs_faq2.html#Hungarian

Snippet explaining what you were interested in in particular:

>I prefer to use underscores to separate words in an identifier (e.g, element_count) rather than alternatives, such as elementCount and ElementCount. Never use names with all capital letter (e.g., BEGIN_TRANSACTION) because that's conventionally reserved for macros. Even if you don't use macros, someone might have littered your header files with them. Use an initial capital letter for types (e.g., Square and Graph). The C++ language and standard library don't use capital letters, so it's int rather than Int and string rather than String. That way, you can recognize the standard types.

There is a good reason beside Bjarne Stroustrup one. When using functors you want them to look like a functions.

But with CamelCase style guides you distinguish Classes from Methods and Functions by using Capitals on the first char of Classes name and LowerCase on the first char of a method.

This is not consistent with c++ algorithm style programming. As there is no reason to distinguish a functor from a function, it's preferable to use c++ and stl coding styles when you want to use functors (and usually you want).

The only rules that truly are needed are those designed to prevent known problems:

• Use ALL_CAPS (plus underscores and digits) for preprocessor names, and only for preprocessor names. It can be tough chasing down problems caused by collisions between a (supposedly) non-preprocessor identifier and a preprocessor name, tougher yet to fix them.
• Never start an identifier with an underscore, and don't have a double underscore anywhere inside an identifier. Those are reserved for the implementation.

Beyond this, be consistent, and don't be too picky. Coding standards should be mindful of rule #0, which is "Don't sweat the small stuff." Far too many coding standards sweat the small stuff.

As far as Google's C++ standard goes, it's not the best. It's more of a C plus or minus standard. It prohibits pass by non-constant reference, for example.