   Standard C++ Naming Convention?
  Hi, just a quick question. What is the most popularly used naming convention in c++? Is it still hungarian?   
Quote:Original post by DenzinHi, just a quick question. What is the most popularly used naming convention in c++?There isn't one (at least not one that is clearly more popular than others).  Usually though, people either use CamelCase or the convention the Standard Library uses (all lowercase with underscores separating words).Quote:Original post by DenzinIs it still hungarian?Hungarian notation is evil and you shouldn't ever use it.  I don't know if Hungarian was ever "most popular," so I can't say if it "still" is, but I'd say (from my experience) Hungarian notation is rarely used.  Anyway, just avoid it.  It just pollutes your names and makes things unreadable.  Though of course this is all just personal opinion.   ;  Pretty much anything that's not Hungarian.I'm partial to lowercase_with_underscores as seen in the standard and Boost libaries.   ;  thanks for the quick response.i've been using camel case but my teacher said something about hungarian (hes old school programmer)   ;Quote:Original post by Denzinthanks for the quick response.i've been using camel case but my teacher said something about hungarian (hes old school programmer)Yeah just forget he ever said that.  Here's what Bjarne Stroustrup said about Hungarian notation:Quote:http://en.wikipedia.org/wiki/Hungarian_notationNo I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding an abbreviated version of a type in a variable name) a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming—both of which emphasize selection of operations based on the type an arguments (known to the language or to the run-time support). In this case, 'building the type of an object into names' simply complicates and minimizes abstraction.;  I use camel case.  Class names begin with a capital and instances/methods begin with lowercase.  This makes it easy to name generic instances:SomethingClass somethingClass;somethingClass.doSomething();I also refuse to attach a special prefix to member variables as well.This convention seems to be somewhat common.  It visually separates your code from std/boost which could be a good or a bad thing.  The more I use boost/std the more I want to use their conventions, but all_lower_case is tougher to read.   ;  I've read an essay which states that the modern idea of "hungarian" notation, where we prefix based upon builtin types and type modifiers, isn't even how hungarian notation was first applied -- which added the prefix based upon the intended use of the variable, rather than its specific type. As an example:/* "modern" hungarian notation */unsigned int uiTimeStarted;/* "original" hungarian notation */unsigned int tStarted;Aside from the reasons earlier attributed to Stroustrup, most modern IDEs have some form of intellisense, allowing you to determine the type of a variable simply by hovering the cursor over it.prepending, aside from member variables of classes, is extremely rare these days. Personally, I prepend protected and private member variables with 'm', and on the rare occasion I deem a global to be warranted, and it is not within a namespace, I'll prepend it with a 'g'. In both cases, a couple purposes are served: first, most IDEs don't reveal the scope of variables through intellisense, and it serves as an easy reminder of what scope it is defined in. Second, it allows the undecorated form of the name to be used in other contexts without conflict, and without relying on capitalization to distinguish between the two -- eg: If I use "gTimeStarted" or "mTimeStarted", I can still use "TimeStarted" or "timeStarted" as a local variable or parameter name, and I can simply say "em time started" vs "time started" when speaking to a colleague on the phone rather than saying "capital tee time started" to distinguish.I think the only thing most people agree on is that constant values are ALL_CAPS with underscore to separate -- this applies to stand-alone constants, and usually to enumerations as well (though I sometimes see enumerations in CamelCase.) -- This also is applied to macros, though inline functions are preferable in most cases, and have the typical function naming convention applies.   ;Quote:Original post by RavyneI've read an essay which states that the modern idea of "hungarian" notation, where we prefix based upon builtin types and type modifiers, isn't even how hungarian notation was first applied -- which added the prefix based upon the intended use of the variable, rather than its specific type.Yes! I'm sick of people bashing Hungarian because of Microsoft's stupid "Systems Hungarian" spin-off (where you prefix the data-type onto the name).In Hungarian the type of the variable isn't supposed to be a "data-type" (int/float/object), but the "meaning" (row-index/health/speed).//MS Systems "Hungarian"float flPlayerSpeed;int   iPlayerHealth;float flUpdated = flPlayerSpeed + iPlayerHealth;//prefixes don't match, are you sure you don't want to use a cast?//Actual Hungarianfloat speedPlayer;float healthPlayer;float healthUpdated = speedPlayer + healthPlayer;//prefixes don't match, are you sure the meaning of this code is correct?;  I used to sort of use hungarian notation but lately think it makes things hard to read and seriously things should be obvious as to what type they are by how they are used.I like do they first letter is captial of every word style iefloat MyData;orclass MyClass;when making enums, types, or consts/define I make them all caps as they are typically ids like float or int but represent a single thing and nothing else ie.const int ZERO = 0;enum MYENUM{    JANUARY=1,    FEBURARY};Member variables for class I always precede with a m iefloat mData;just because within functions it makes it easier for me to see what is a passed in data and a member data, especially with some of the code that I wrote almost 4 months ago and today I had to go throught it again to debug why something was not working the way I thought it should.as for struct member I make the first letter lower case the rest of the first letters are upper case. ie.float myDataType;orfloat value;Most of these things are just things I've seen common amongst most the third party libraries I've used or read thorugh, and I've always found that if I keep my conventions similars to the libraries ?I use it's easier to read through code and write it.Though I do have parts of my old code that uses my old conventions. I just rather not mess with somethings that arent broken... somtimes I take the time to convert to my standard conventions, since somethings I wrote years ago and still use.   ;Quote:Original post by HodgmanIn Hungarian the type of the variable isn't supposed to be a "data-type" (int/float/object), but the "meaning" (row-index/health/speed).//Actual Hungarianfloat speedPlayer;float healthPlayer;float healthUpdated = speedPlayer + healthPlayer;//prefixes don't match, are you sure the meaning of this code is correct?In C++ you'd rather write:float healthUpdated = player.speed() + player.health();// orplayer.health(player.speed() + player.health());