

Every programmer has a variable naming philosophy - marketer
http://research.swtch.com/2010/02/names.html

======
ryanelkins
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.

~~~
rsclarke
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'.

------
meese_
This reminded me of a previous comment (and discussion) on HN:
<http://news.ycombinator.com/item?id=840331>

"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."

~~~
uriel
That is a beautiful analogy!

Like all analogies, it is not perfect, but it fits very well with a good
naming philosophy.

------
thaumaturgy
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.

~~~
lmkg
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?

~~~
thaumaturgy
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.

[1]: <http://www.joelonsoftware.com/articles/Wrong.html>

------
sdh
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.

