Ask HN: Do you name_your_variables, or nyv? Is shorter always better? - chatmasta
======
weddpros
Longer names also force me to describe the variable's purpose: I must know the
variable's purpose. It's easier to code when you know exactly what your code
is supposed to do. Longer names capture that. They help me have a clearer
intent for the code I write.

But some people use vision more, some audition... Maybe we code accordingly.

~~~
sova
Excellent point. It's also like describing an algorithm you just learned to
someone else: the ability to describe it in the right fashion is directly
proportional to how well you understand it for yourself. Thanks for your
reply!

------
sova
Since learning clojure I've really come to appreciate that descriptive names
are better than short ones.

It depends on context, but many-named-functions exhibit-long-groupings for-
sake-of-clarity. It's easier to come back to code months later and know what's
going on. If you are doing simple math, like a dot product, naming your
vectors u and v is not a big deal that much is obvious. However, if you have
to document out what a variable stands for, you might as well use a long name;
bytes are cheap, addresses/references are internally the same length they
would be whether or not you named the variable g or george-harrison, and
humans are the ones reading and editing it, not robots.

I would argue that longer is better, for the above reasons, and that is one
big difference between 16-year-old coder-me and current-coder-me.

------
onion2k
Argument in favour of short variable names;

1\. They're quicker to type.

Arguments against them;

1\. You can tell what they mean by reading them. 2\. Other people can tell
what they mean by reading them. 3\. Tab completion is a thing.

It's a no brainer.

~~~
SlipperySlope
When I began programming in 1968, Fortran IV offered upper case variable names
up to 6 characters long. Often the first character was used to implicitly
define the type, e.g. a variable denoting an integer began with "I". The
convention of using a variable named "i" to denote an loop index took hold
with Fortran.

In 1973, I began programming in COBOL, which was again upper case only with
regard to variable names but allowed 30 characters, often consisting of domain
relevant words separated by dashes, e.g. "INVOICE-NUMBER". This was so much
better than FORTRAN. The theme of COBOL was to have a computer language that
read like English. For example, "DIVIDE ACCOUNT-INCREASE BY DAYS-IN-MONTH
GIVING AVERAGE-INCREASE-PER-DAY."

When I began programming in Smalltalk and Java in the 1990's, the variable
names could be very long, and I used the Camel case style of composing names
without separation characters, e.g "invoiceNumber".

Because I have a strong interest in automatic programming, I try to write code
as it would be written by an AI. I favor variable names in Java that mirror
the object type, e.g. "stringBuilder", "outputStream",
"propertyEditorManager". The rationale is that if the AI creates the variable
names, there is a simple rule for forming them, and the length is no bother to
the human who does not actually type them, but simply reads them.

