John said:
Because of the limitations of a linker?
There are two aspects to the proposal.
The main aspect (in my opinion) was that the "type" (as determined by
usage of the variable, NOT the type system of the language) of the
variable should be indicated in the variable name. So if a variable is a
length it should indicate this in the name (and if you have lengths in
cm and inches in your program, you should indicate that too in your
variable names, lest your space probes miss their targets). That part is
still valid, I think. Especially in a typeless language like perl.
(BTW, BCPL was a typeless language, too)
The second aspect is the specific form: Single- or double-character
lower case prefixes before an upper case variable name. This aspect is I
think an artifact of the development environment he was using at the
time: Long variable names simply were impractical then, and if you've
ever used a VT100 terminal, you know why most unix commands are so short
. This aspect is IMHO obsolete.
In that case, the original proposal (which I haven't read, so I might
be wrong) should have included that the system is a work around for a
linker issue.
I read that paper about 15 years ago and I don't remember whether it
included that or not. It may have. But even if it hasn't that's hardly a
fair critique. It was written at a time when severe limits on identifier
names were *normal*. It wasn't a workaround for the limitations of a
specific linker. Most linkers and programming languages had limitations
on the length of their identifiers, and a proposal which would have
required 30 character variable names would have been laughed out of the
door because nobody would have been able to use it. You have to consider
the time when a paper was written, especially in a fast-moving field
like IT.
If it does, it's short, and has a few variables which probably don't
need a lot of explanation in their names.
No, I'm specifically talking about long formulas. A short formula is
easy to understand whether it takes half a line or three. But a long
formula is a lot easier to understand if it fits on a line or is broken
into a few lines according to the structure of the formula than if has
to be split onto 20 lines in completely arbitrary places just fit
horizontally into the editor window.
The advantage of splitting a non-trivial formula over several lines is
that it can be documented per line
Another reason to use short variable names: Leaves more space for your
inline comments.
A formula in a text book is read in the context of the page it's on.
It often has some explanation of all variables. It assumes you read
the context.
A formula in a program must be read in the context of the function it's
in. Explanations of the variables can be included at the declaration of
the variables. Scope should be used to minimize the context that the
programmer has to consider.
With programming, I prefer to have the context as close to the real
thing as possible, and if I can make things clear by formatting my
code, and picking good names (etc), I prefer that over a comment
block.
I agree with that completely. I am just arguing that with variable
names, "long" does not equal "good". A variable name should be long
enough to make the purpose of the variable clear, but no longer.
As an example, consider a loop like
for my $i (1 .. $#src - 1) {
$result[$i] = (sort { $a <=> $b } @src[$i - 1 .. $i + 1])[1];
}
vs.
for my $source_array_counter (1 .. $#source_array - 1) {
$result_array[$source_array_counter] = (sort { $a <=> $b }
@source_array[$source_array_counter - 1 .. $source_array_counter + 1]
[1];
}
Using $source_array_counter instead of $i for the loop variable does not
make the code more readable, quite the contrary.
hp
