Every programmer has a variable naming philosophy
research.swtch.com
research.swtch.com
Perhaps I've just had to work with too much code that has poorly (in my opinion) named variables.
Then again I also have intellisense and autocomplete so I don't really fear a slightly longish variable name if it makes sense.
Another good reason is that I use search to navigate through files, and verbose names are easier to search for.
I was taught camel case for everything, which I don't agree with. Camel case for class names, everything else lower case, short and separated with underscores if needed. Collections are plural, e.g addresses, so that one can be generic in iteration and talk of an 'address'.
"Another way to look at this: The first time you meet someone, you learn their full name. When discussing them with someone else who knows them, you use just a single name. If they're standing right there, you don't bother using their name, but just make eye contact, and maybe a "Hey". Should be the same way with variables."
Like all analogies, it is not perfect, but it fits very well with a good naming philosophy.
kVariable: A constant value, even in languages that don't support constants. Usually either a semantic shortcut for some value, or for some knob that can be turned at the top of the code.
xVariable: A local variable.
gVariable: Global. (I care much more about variable scope than I do about variable type.)
x, y, z, i, j, k: Counters. I try not to nest or overuse these too much. If it starts to get hard to follow, then I rename them.
There are a couple of other hints that I leave myself too. For example, I tend to pluralize the names of variables that contain arrays or lists of things: xWindowElements for example.
I never cared for Hungarian notation or its brethren. To me, it just had too steep of a learning curve for too little payoff, and didn't even convey the information that I usually needed.
After thinking about it more, I think I've decided over the years that problems like variable type should be handled in the architecture, not the variable names. If encoding your variable types in your variable names is doing you any good, then either your functions are getting a lot longer than they really ought to be, or you've got more globals than you should, or you aren't correctly handling objects.
I think this is true even for Apps Hungarian. It looks like Joel's article [1] is one of the most-cited resources on Apps Hungarian, and the specific example he uses is for signaling safe versus unsafe strings in a web application. He comes up with a somewhat convoluted example of why you might want to keep an "unsafe" string around, but I don't buy it. Every single input in a web application (for one example) should be vetted before any processing on the input takes place. You might not want to HTML-encode a string going to your credit card interface, but you certainly do want to validate it.
This is actually even more the case in things like traditional C/C++ applications, because the code bases get so much larger than the average web application. By the time you get to inner functions, they shouldn't need to care whether the input is correct or not; it should have already been handled elsewhere.
The one exception to this -- in my case anyway -- is in resolving variable scope. If I'm starting to use too many globals, it's hard to ignore lots of "gSomething" all over the place. That's a signal to me that it's time to re-think what I'm doing. Likewise with the loop counters. Prepending "x" to local variables just reduces name collisions with other functions and objects and whatnot.
Local variables are usually distinguished by starting with a lower-case letter, as the codebases I work with have global and method identifiers start with capitals. Global variables, to a first approximation, are never used: I have never known a case where the use of global variables wasn't regretted in the longer term. But a g_ prefix wouldn't be out of place if they must be used owing to an old codebase already littered with them.
As to "counters": for indexing for-loops, at best i through k are used - if more are needed, subroutines are used instead, so i through k can be reused. Other things that count have better semantic names than single letters.
Isn't the point of adhering to a style so that others will already be familiar with it?
I have seen the kVariable style, and of course the iterator convention. I have never seen the other two, however; usually globals are denoted with all-caps and locals are just assumed (xVariable seems annoyingly superfluous). That's just my opinion, though — if I were coding in a language where your style was the most common, I would use that instead.
When working on others' code, I do adopt their style, including their braces and so forth.
But for my own stuff, my style is more comfortable, and I think that when other people see it, it's pretty clear what's going on.
I assume the author isn't saying that all variables should be named like "i" and "j" (and those examples are bad ones since they are well-known conventions), but that a variable shouldn't be named any longer than is needed to convey meaning.
Ok. Why even make this point? Programmers should err on the side of too long rather than too short. And, whenever possible, use the conventions of the language in favor of their personal philosophy.