Lots. As a programmer I learned very quickly that I’m one of those types of people that makes strict conventions and adheres to them whenever possible. Variable naming styles play a huge role in this. Before I delve into detail on my own style, how about a few comments on some of the general variable naming conventions that are out there today?
Variable naming conventions actually have two components to them: the “formatting convention”, and then the actual naming convention itself. The formatting convention mainly deals with how the name is presented, such as the case, any additional punctuation like underscores, etc. The naming portion of the equation is how the programmer selects what to call the variable. Pretty simple.
Formatting is definitely the most straightforward to talk about, as there really isn’t a whole lot you can do in that department. The most popular style seems to be camel case, e.g. “myVariable”, “myByteBuffer” and “someUselessObject.” Camel case is easy on the eyes for variables that are constructed from multiple words, allowing for variablesWithLongerNames to still be readable. It also seems to emphasize the parts of the variable with capitals, which are also generally the more important part, i.e “ByteBuffer” in “myByteBuffer.” The other popular alternative involves the use of underscores to separate parts of the variable. Rewriting the previous variables in this underscore style would give “my_variable”, “my_byte_buffer” and “some_useless_object.” Allow I suppose you could do a hybrid, something like “my_ByteBuffer” or “my_Byte_Buffer”, most people seem to go one way or the other. I’ve also seen underscores prefixed on variables, like “_byteBuffer”. I’m not really sure what this accomplishes though. In fact I personally think the underscores look atrocious, but for the sake of variety will continue to use them for one more paragraph.
On to the names themselves. These can’t really be divided up as easily, as there are lots of different ways to go about the task. One convention I’ve seen pretty often is including a letter or two to indicate type for standard type variables, like “fSpeed”,”bRun”, or “ch_initial.” For arrays and lists it’s uncommon to see “scoreList” or “item_array.” It definitely makes it clear what the variable in question is. Another convention is to include the variables scope in the name. A class member might be named “mTimeStamp”, while a variable passed in as a parameter might be “p_rate”. There are clearly lots of ways to tackle the problem of names, but as long as the name makes sense in the context is really just a matter of preference.
What about me? Well, as I may have hinted before I’m a big proponent of the camel case style formatting convention. All of my code uses it all of the time, local variables included. I’m also equally picky about my var names. All variables are named based on scope/location, as mentioned above. Global variables get the “g” prefix, members get an “m”, parameters a “p”, enums an “e” and so on. As far as the rest of the variable name goes, I always follow three simple rules:
1. Keep it as short as possible. Make sure that the name is only as long as it has to be in the context that its given. “mTextFileArray” can be shortened to “mFileArray” if it’s used in the “TextFileManager” class, for example.
2. Name it after its purpose. This is the most important rule, in my opinion. Lets say we’ve got a “Weapon” class. The name “mCount” as member variables leaves a lot of questions, as it there are a variety of things that could be counted. “mAmmoCount”, “mClipCount”, or “mFireCount” are much better. Of course, as per rule #1, in the case of “void setAmmoCount( int pCount )” pCount works just fine since the context implies ammo.
3. Name the type if it could be ambiguous. For things like floats/doubles, or ints/shorts/longs this isn’t something I do. Its more in the case of something like “mItems”, where the better option would be “mItemsList” if it’s a linked list, “mItemsPtr” if its a pointer to an array, etc. This rule definitely has more flex to it than the others, and is kinda on a per-case basis.
The bottom line is, I do my best to make sure I don’t have “int temp” or “float testvar” in my code. In situations where I’m trying to pound out a big piece of program quickly I will occasionally let the style go, but this just creates more cleanup work later so I’ve found its best to get it right the first time.
And, by no means are these rules the “right” ones to follow. I’m a self-taught programmer so I probably do some quirky thing, naming conventions included. Like I said before it’s really all a matter of personal preference. Unless you’re doing work for someone else and they enforce code conventions, finding something that works for you is just another part of learning to program.