Here's mine, just for fun. I haven't seen anyone else using anything like it.
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.
That looks to me like a variant of Apps Hungarian, encoding variable use. When you say you don't like Hungarian, do you mean more specifically that silly Systems Hungarian that encodes concrete data type?
Yeah, I was thinking more along the lines of Systems Hungarian.
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.
I prefer not distinguishing lexically between e.g. constants and static properties / global functions (depending on the language features), etc. Many constants represent configuration choices, rather than actual mathematical or physical values that will never change.
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.
> I haven't seen anyone else using anything like it.
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.
"gVariable" was common back in things like "Tricks of the Mac Game Programming Gurus" and the like, years ago. I think it's an old Pascal convention, but I'm probably wrong.
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 like to be somewhat verbose with my naming. I don't like to abbreviate unless its a very common and well understood abbreviation. If nothing else because I can have a terrible memory and find myself struggling to remember exactly what a variable is storing otherwise. I can't imagine what it would be like for a different programmer entirely.
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.
I do not like long variable names and believe it is a combination of good commenting and inference through the code, that one should understand the role of the variable.
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."
Why does it matter if a variable name is longer than it should be? As long as the code is legible, who cares?
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.
12 comments
[ 4.3 ms ] story [ 39.9 ms ] threadkVariable: 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.
[1]: http://www.joelonsoftware.com/articles/Wrong.html
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.
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.
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.