Topic: Why is Autolisp variable naming so terrible?

[ElpanovEvgeniy]

I totally agree with MP!
First of all, there's personal habit.
If I work in a team where you want to share my code, I will call all the variables in great detail. To themselves or offline, I write short and fast.
Maybe I'm too lazy 

[alanjt]

I think another important factor is consistency. I'll admit to using e, d and i quite a bit, but they are always for entity, data (entget) and increment (stepping through a selection set). Another good thing about consistency is being able to copy a snippet of code from one routine to another and not having to change the variable names.

The variables that should always be verbose are the global ones. I hate seeing a global variable such as doc or the like. I've taken on using *<RoutineName>:<VariablePurpose>*.

Hell, for a lot of the document variables, I noticed Jeff_M and a few others used *acad* and *AcadDoc*, etc. as global variables. I started using the same naming convention long ago so I can take advantage of already stored variables in my code or theirs.

[ElpanovEvgeniy]

I have a question for you, if the variable is created for only one use in the next line if you want to call it in great detail, or rather one letter?

For example, the variables A and B:

Code: [Select]

(vl-sort lst '(lambda (a b) (<= (car a) (car b))))
offer your variable names for this example 

[MP]

c'mon Evgeniy, you know anything more verbose than that example would be superfluous. It's perfect as is, you're just teasing now.

[ElpanovEvgeniy]

I will not tease - in Moscow sechas 2:15 am and I went to bed ...
Once again, if the variables are far from each other, if the variables are global, if in the same function are so many variables, I also use detailed titles!
Оne line, I think, and you use a single letter.
All that is between these examples differ only in the personal perception of large and small code. Someone used to working only with a little code, and the other with a huge. for me 100 - 200 lines of code, is a small code and I keep it entirely in memory and in memory of his editing.
ps. in his mind, and not a computer

[VovKa]

i usually use long camelcased variables, i believe it makes my code selfcommenting

[BlackBox]

The veteran CAD guys at my work only learned AutoLISP (except for one or two), and only use small variable names in their code. I found it hard to read and comprehend, and try to use camelCase variable names for readability where I can.

Given that I am relatively new to coding (1-2 years), consistency hasn't always prevailed.

Especially now that I've been learning .NET namespaces, I prefer them (longer variable names) as well.

[Kerry]

  By definition source code is human-readable text that can be converted to machine language.
  The important concept here is human-readable. If code fails this test the code does not fully serve it's function.

By definition a variable is a named placeholder for a value.
  If the name of the placeholder reflects the nature of the variable the code will generally be easier to understand.

My take on using 'terrible' variable names.

it depends !

On what :
  How good is your memory.
  Do you want to share the code.
  Will you be able to glance at the code in 12 months and understand it without scratching your head.
  Will anyone you show the code be able to do the same. [ can it be maintained by others ]
  What mood were you in when you wrote (or read) the code.

Generally I find it easier to read and quickly understand code that has meaningful variable names.
  ... both my code and the code written by others.


[/Personal Opinion]

Regards

[JNieman]

Because nerds.

[cmwade77]

I have been trying to use some standard naming in my routines recently, as follows:
Ent, Ent1, Ent2, etc. - Entities from using things like Entsel
Obj, Obj1, Obj2, etc. - VLAX objects
Str, Str1, Str2, Txt, Txt1, Txt2, etc. - Text
Pt1, Pt2, Pt3, etc. - Points

If it is something unique, then I try to use something descriptive. I use HippoEdit, which remembers the variables used, so I only have to type the first few letters and it takes care of the rest, so that helps with that as well.

[hermanm]

Does the length of a variable's name affect memory or does it get bound to the memory address or something other arbitrary value?

1. Back in the day, AutoLISP allocated "string space" for variables with names exceeding 6 chars (IIRC).
May still do so, I don't know.

For anyone who started programming AutoLISP on early PCs, memory was a big deal. Clearly not so today.
As well, execution speed might be compromised if accessing a variable name required an extra step (speculating - I do not know the exact mechanism of string space allocation).

2. Many, if not most, AutoLISPers are mathematically inclined and trained. So, there may be a natural tendency for variables in AutoLISP programs writen by such people to reflect what you might see in a math, science or engineering text (angle a, point p1, etc.).

3. Brevity of typing, as others have stated.

[MeasureUp]

Just reply to the OP's question, it is up to the Lisper.
I do agree it would be headache when people always do things in their own ways, especially when you have a piece of their routines.
However, they can do and will continuously do what they want if the routines are not shared with the public.
My preference is to get those variable names longer enough in length for allowing me to remember what they mean/do in the latter days.

[CAB]

Other thoughts on the subject. 
http://www.theswamp.org/index.php?topic=1786.msg22798#msg22798
http://www.theswamp.org/index.php?topic=35533.0
http://www.theswamp.org/index.php?topic=782.msg10722#msg10722

[Lee Mac]

Most of the time I will try to use semi-descriptive variable names, such as 'lst' for a list, 'p1', 'p2' etc for points, 'en' or 'ent' for entity; particularly when working with ActiveX, I try to be consistent, using 'acdoc' for ActiveDocument, 'acblk' for the ActiveDocument Blocks Collection, 'aclay' / 'aclyr' for Layers Collection, etc. This makes life easier when interfacing with ObjectDBX, since the ODBX doc variables can be named correspondingly... 'dbxdoc', 'dbxblk', 'dbxlay'... etc.

Other times, when writing small snippets of code, I am admittedly lazy with variable naming, such as this recent example; and then there are times when I will write obfuscated code just for the heck of it.

[Jeff H]

Thanks for all your input and I was joking around with the 'terrible' comment.