Re: Not intended for use in medical,

[kaz@vision.crest.nt.com (Kaz Kylheku)]

In article <dewar.863062734@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Robert Duff said
>
><<I agree (except I'd remove "perhaps").  There's nothing wrong with
>having short-hand notations like "++" and "+=".>>
>
>There is something potentially wrong, which is that compact operation
>notations like this are most happy with short identifier names, as in
>
>   a++;
>
>not nearly so pretty is
>
>   Average_Daily_Rate_Of_Pay++;
>
>and indeed if you speak the above, it comes out as a joke, people laugh.
>
>Well of course this is not the only reason that C programmers so often
>favor short cryptic identifier names (and of course there is nothing in C
>which requires them), but it is a contributing factor!

There are all kinds of good reasons; those short cryptic identifiers offer
better readability.

Of course, Average_Daily_Rate_Of_Pay sounds like a fundamental quantity in
the program; a good programmer would not give it a short identifier 
such as ``adrop''. In fact a coder might not even have the freedom to choose
the name, since that name may be part of a data dictionary that came from
the design stage.

But disposable local variables that have an implementation-oriented
meaning---such as loop counters, temporary pointers and the like---should be
given nothing but short names. To do otherwise would ascribe to them
a significance that they do not have.

What's the point of calling something ``Loop_Counter'' instead of ``i''?
Or ``Destination_Buffer_Pointer'' instead of ``dp''? It's just distracting.

It can also quickly lead to code that is wider than 79 columns, and that 
is a Bad Thing (tm).

Here is an example with short, cryptic variable names from a reference
implementation of an encryption algorithm of mine. Notice that not
all the identifiers are short; there is ``rhyme and reason'' behind
the selection of which objects have short identifiers.

void pha_encipher(pha_cblock *plain, pha_cblock *cipher, pha_schedule *sched)
{
    pha_cblock_internal a, b;
    unsigned long (*piece)[2] = sched->piece;
    int r;

    make_internal_cblock(plain, &a);

    b[2] = a[0];
    b[3] = a[1];
    for (r = 0; r < ROUNDS; ) {
	a[0] = apply_sbox(0, (mult_combine(b[2], piece[r][0])));
	a[1] = apply_sbox(1, (mult_combine(b[3], piece[r][1])));
	rotate_left(a);
	a[2] = a[2] ^ a[0];
	a[3] = a[3] ^ a[1];
	r++;

	b[0] = apply_sbox(2, (mult_combine(a[2], piece[r][0])));
	b[1] = apply_sbox(3, (mult_combine(a[3], piece[r][1])));
	rotate_left(b);
	b[2] = b[2] ^ b[0];
	b[3] = b[3] ^ b[1];
	r++;
    }
    b[0] = a[2];
    b[1] = a[3];

    make_external_cblock(cipher, &b);
}

I can't think of a reasonable name to give to the two intermediate
cipher blocks other than 'a' and 'b'. I could have called them 'L' and 'R',
except that their roles exchange after every round. The code is confusing
enough without being made lexically incomprehensible with long names. It's
important that the array indices ``stand out'', which makes them easy to
inspect for errors. I originally had longer names, but it was unmanageable.