Re: [dwm] Documentation!

From: Charlie Kester <>
Date: Sun, 18 May 2008 13:40:04 -0700

* Steffen Liebergeld <> [2008-05-18 19:38:00 +0200]:

>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:

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

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.
Received on Sun May 18 2008 - 22:40:39 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 15:40:40 UTC