>>>
>>>Tom, I agree its a bad idea for no other reason than simply that "a" is meaningless as a file reference while an alias eg "Debtors" is meaningful.
>>
>>Jos,
>>Not even that can be a really valid reason. We're talking here about the use of single letters as aliases in a sql-select. The sql-statement is always occupying only some lines. There's no risk of mis-interpretation, since the place where the alias is declared is so near-by for the eyes.
>>Usually, when there are several tables involved in the sql-select, I use single letters that somehow have a link to the table, like an e for the employee table, or a c for the costplace table. But I won't blame anyone, including myself, if there's no seeming relation. So, if someone wants to use the a for the employee table, than it's fine with me.
>
>Peter, IMO single letter names are meaningless in almost any situation including for variable names. They say nothing. Proper alias names help one understand the code. But its only an opinion.

Hi Jos,

This thread was not about standards. And the start of this part of this thread was just a funny anekdote. See Message #837335.
Tamar Granor's reaction was IMO all too serious: Just want to point out that using A as an alias is generally not a good idea. Much better to use the actual alias.

I felt a need to respond anyway. The reason is that I think that such statements ('..is generally not a good idea...') should be based on one or more arguments, at least here on the UT. There was no argument and IMO there's still no VALID argument, yours included. Maybe the arguments are good enough for you, Tamar and Tom, but they are really not good enough for a 'superb standard'. On the contrary, I'd say..

Why? It's really asked too much if you want programmers to always use a meaningfull alias or variable name. Sure, that must be the case if the alias/variable is used in a large piece of code, but if it's only a single sql-select or if it's only a very small FOR/NEXT, there's no problem if the programmer uses a single letter A or a variable named lnN (as an example). All the relevant code is within the view of the reader and therefore no interpretation problem should occur. Compare:

FOR lnThisField = to alen( laField, 1 )
    *
    ? lnThisField, laField[ lnThisField, 1 ]
NEXT

FOR lnN = 1 to alen( laField, 1 )
    *
    ? lnN, laField[ lnN, 1 ]
NEXT

Is the second part really less clear?? Not for me. (Maybe it's even clearer, thanks to the fact that it's more compact!)

Hey, I'm the person who, generally speaking, corrects colleagues telling them to use meaningfull names. But, please, let's not exaggerate!

BTW, I only use names like lnN, lnN1, lcC, lcC1 for such constructs. Here's the logic: Only these types of variables are re-used in the same piece of code. For the rest, I use many-many meaningful (local) variables.