* Steffen Liebergeld <[EMAIL PROTECTED]> [2008-05-18 19:38:00 +0200]:
Hi,
Anselm R. Garbe wrote:
On Sat, May 17, 2008 at 12:21:59PM +0200, yy wrote:
The 2 or 3 characters variable names have been there since the
beginning to define geometries, I don't understand what the problem
I kind of prefer short variable names, they are much easier to
read, especially in calculations. If you solve an equation with
your pen, you also don't use variable names like
heightOfTheHouse / sqrt(frontSideOfTheHouse * leftSideOfTheHouse)
h / sqrt(a * b)
is more readable. I agree of course, that h, a, and b should be
described somewhere if they are intended being manipulated in
the users setup.
I completely disagree with you. First of all, your pen and paper equations
are used only one time and that is when you do the equation. Afterwards you
throw the paper away and go with the results. When programming, you have to
make sure that the code is read- and understandable when you get back to
it. What makes good code is how fast you can grasp its workings when first
reading it (when you read your code after a year of not touching it, it is
like the first time you encounter it). And it is not a good thing to have
short variables and document them somewhere else. Have you ever heard of
the Single Point Of Truth (SPOT) rule? If not, read that:
http://www.catb.org/esr/writings/taoup/html/ch04s02.html.
I'm sorry, but I for one disagree with *you*.
The issue, imo, is about achieving an optimum balance between clarity of
variables and clarity of program structure. The problem with long
variable names is that they can obscure structure, That's the point of
arg's example. The math is much more discernible using short variable
names.
What good is it to understand the semantics of the variables if it comes
at the expense of understanding the algorithm?
Perhaps this helps explain the value of the SLOC metric. It's only a
hunch, but I suspect that the need for long variable names is something
that arises mostly in the context of large programs, where it's harder
to keep track of things. The smaller your code is, the more you can
afford to emphasize structure over semantics.
