views:

354

answers:

4

I am quite confused by looking at the boost library, and stl, and then looking at people's examples. It seems that capitalized type names are interspersed with all lowercase, separated by underscores.

What exactly is the way things should be done these days? I know the .NET world has their own set of conventions, but it appears to be completely different than the C++ sphere.

+7  A: 

What a can of worms you've opened.

The C++ standard library uses underscore_notation for everything, because that's what the C standard library uses.

So if you want your code to look consistent across the board (and actually aren't using external libraries), that is the only way to go.

You'll see boost use the same notation because often their libraries get considered for future standards.

Beyond that, there are many conventions, usually using different notations to designate different types of symbols. It is common to use CamelCase for custom types, such as classes and typedefs and mixedCase for variables, specifically to differentiate those two, but that is certainly not a universal standard.

There's also Hungarian Notation, which further differentiates specific variable types, although just mentioning that phrase can incite hostility from some coders.

The best answer, as a good C++ programmer, is to adopt whatever convention is being used in the code you're immersed in.

Shmoopty
I recommend reading about Hungarian Notation. +1 to Apps Hungarian Notation, -1 to Systems Hungarian Notation (see if I can get people into reading the article)
David Rodríguez - dribeas
@dribeas: I stumbled on that article recently, and I agree with you. I had to unlearn my reflex hatred of any Hungarian Notation based on the Systems variety.
Harper Shelby
@Harper: true, but _real_ hungarian notation can be useful: [[ double mLengthOfFootballField = 109.7, umHumanHairGrowthPerDay = 400; ]] You can detect bad expressions by mixing prefixes: [[ mpsDecentRate = ftAltitudeDelta / sTimeDelta; // <-- bad! ]]
Aaron
*incitation of hostility*
coppro
+3  A: 

There is no good answer. If you're integrating with an existing codebase, it makes sense to match their style. If you're creating a new codebase, you might want to establish simple guidelines.

Google has some.

tfinniga
A: 

It's going to be different depending on the library and organization.

For the developer utility library I'm building, for example, I'm including friendly wrapper modules for various conventions in the style of the convention. So, for example, the MFC wrapper module uses the 'm_typeMemberVariable' notation for members, whereas the STL wrapper module uses 'member_variable'. I'm trying to build it so that whatever front-end is used will have the style typical for that type of front-end.

The problem with having a universal style is that everyone would have to agree, and (for example) for every person who detests Hungarian notation, there's someone else who thinks not using Hungarian notation detracts from the basic value of comprehensibility of the code. So it's unlikely there will be a universal standard for C++ any time soon.

Nick
especially after 20 odd years of "wanting one" :)
baash05
A: 

Find something you feel comfortable with and stick with it. Some form of style is better than no style at all and don't get too hung up on how other libraries do it.

FWIW I use the Google C++ style guide (with some tweaks).

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Rob
I don't like the Google C++ style guide - it recommends avoiding features like exceptions, which is just awful coding practice (granted, that could be one of your modifications, I don't know)
coppro
To be fair, it doesn't really *recommend* avoiding exceptions. It just acknowledges that because they have a non-exception-safe codebase, starting to use them in new code would be costly: "Things would probably be different if we had to do it all over again from scratch".
Steve Jessop
That said, IMO it's possible to work exception-using code gradually into an unsafe codebase, *provided* that you're disciplined about what APIs can throw exceptions, and you provide exception-catching adaptor APIs where necessary. But I can see why any company might not want the pain.
Steve Jessop