Topic: Why is Autolisp variable naming so terrible?

[Jeff H]

This is not aimed at anyone particular and have noticed it done by many of the good ones here.

I was just wondering why and does it ever cause problems naming your variables l, a, s, d, m, etc....
 
I do not see how you can keep up with them or do the one letter variables usually represent the same type from program to program?
 

[ElpanovEvgeniy]

I use the name for the list L, P for the point, I refer to other variables as given. Typically, the local variables used in a number less than 1000 lines of code, I use only one letter. If I have several identical within the meaning of variables, such as two points, I add a number, for example P1, P2 ... Most often, I use the letters that are easy to press with your left hand - right more often occupied by the mouse.

[MP]

<imo> When it's done by senior members I believe it's (a) probably a carry over of old habits formed when even variable name length (other programming platforms, not AutoLISP) cut into available programming memory, or (b) typing frugality, or (c) an unfortunate misconception that brevity is king. Concise is nice but not at the expense of algorithm clarity. Lucid > brevity. </imo>

[alanjt]

<imo> When it's done by senior members I believe it's (a) probably a carry over of old habits formed when even variable name length (other programming platforms, not AutoLISP) cut into available programming memory, or (b) typing frugality, or (c) an unfortunate misconception that brevity is king. Concise is nice but not at the expense of algorithm clarity. Lucid > brevity. </imo>

When I took programming in high school, the teacher made a comment about short variable and command names because it was memory and that typing wasn't as easy on the older mechanical keyboards, thus, commands/functions were kept at only a few letters. Would you agree/disagree with that?

[MP]

Would you agree/disagree with that?

yes

[alanjt]

Would you agree/disagree with that?

yes

arg, poor wording. Do you agree or disagree with my above question? 

[ElpanovEvgeniy]

<imo> When it's done by senior members I believe it's (a) probably a carry over of old habits formed when even variable name length (other programming platforms, not AutoLISP) cut into available programming memory, or (b) typing frugality, or (c) an unfortunate misconception that brevity is king. Concise is nice but not at the expense of algorithm clarity. Lucid > brevity. </imo>

my code

Code: [Select]

(defun test (l / f)
  (defun f (a l) (if a (* (atoi (caddr a)) (f (assoc (cadr a) l) l)) 1))
  (mapcar (function (lambda (a) (append a (list (itoa (f a l)))))) l)
)
here
L - list
F - function
A - more info
The code is small and intuitive
If it is to increase the length and clear variables, it will be worse than to read and understand! It is a small amount of code allows you to see the algorithm at once.

PS. I think that variables should always be shorter function names. Otherwise, the variables will be obscure the code...

[MP]

arg, poor wording. Do you agree or disagree with my above question? 

Not trying to be more of a dick than my usual cantankerous self ... you quoted my first post but I wonder if you actually read it. Subtitle: I believe I answered your question in advance.

[Jeff H]

Do you agree or disagree with my above question? 

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

[ElpanovEvgeniy]

All the variables, it is only a reference to the storage location information.
The size of the variable name, it is easy to read code and the size of the source file.

[alanjt]

arg, poor wording. Do you agree or disagree with my above question? 

Not trying to be more of a dick than my usual cantankerous self ... you quoted my first post but I wonder if you actually read it. Subtitle: I believe I answered your question in advance.

Dammit! LoL
Do you agree with my above question about lengths of command names and stored variables? 

[MP]

ElpanovEvgeniy my friend, I have always admired your intellect and acuity, but I cannot agree that (generally speaking, not the simplistic example) "the code is intuitive" or that "if it is to increase the length and clear variables, it will be worse than to read and understand". As we are both of strong opinions we will have to disagree upon the manner in which food is spiced while agreeing we both love to cook.

[Jeff H]

Just seems eaiser to read
startPoint
endPoint
vs.
p1
p2
 
I am not good at smart people stuff so that might have something to do with it.

[ElpanovEvgeniy]

took the sample code here: http://www.theswamp.org/index.php?topic=31524.0
my variant variable naming

Code: [Select]

(defun test (l / f)
  (defun f (a l)
    (if a
      (* (atoi (caddr a)) (f (assoc (cadr a) l) l))
      1
    )
  )
  (mapcar (function (lambda (a) (append a (list (itoa (f a l)))))) l)
)
variables used in the code xianaihua

Code: [Select]

(defun test (bom_lst / SumPartCounts)
  (defun SumPartCounts (assembly bom_lst)
    (if assembly
      (* (atoi (caddr assembly)) (SumPartCounts (assoc (cadr assembly) bom_lst) bom_lst))
      1
    )
  )
  (mapcar (function (lambda (assembly) (append assembly (list (itoa (SumPartCounts assembly bom_lst))))))
          bom_lst
  )
)
Shorter code, it seems to me clearly.
Maybe I'm reading the very structure of the program and give it more attention than the meaning of data variables.

I read that programmers use Lisp, do not use flow charts of the program. For LISP programmers to program itself this is a scheme.
Perhaps that's why I do not need long variable names on the short code.
ps. a long code, I give a long and meaningful names to variables, which can be used rarely and far between.

[MP]

At the risk of pointing out the obvious, there is a balance, that admittedly, varies from person to person, with regards to economy vs lucidity. I've no problem with p1, p2 or even i for that matter, when it's an iterator etc., but when a code snip is comprised entirely of single letter variables I find I easily glaze as the code turns into one mess of an ascii stream, though the lack of carriage returns / white space is another contributing factor. Oh crap, another can of worms opened ...

[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.

[nivuahc]

I've been using PascalCase naming for my variable for the past few years for one reason; I'm getting old. I've wasted more time looking through older snippets of code that I'd written, trying to parse in my head what it was doing, that could have been cleared up had I used better variable (and function) naming.

I once had a job where I was tasked with updating all of a companies internal routines to work in R14 (from R13 running on Unix). The previous programmer named a lot of his functions things like doit and dothis and all of his variables were single letter with the occasional numeral (i.e. a1 a2 p1 p2).

And did I mention that the previous programmer was allergic to commenting?

It became easier in the end to run his code, see what it was supposed to do, and just re-write a lot of it from scratch.

Using PascalCased or camelCased names, as already mentioned, almost makes the code self-commenting.

[Dashmonkey]

and then there are times when I will write obfuscated code just for the heck of it.

That's just F/M/L soup!

Really though, I had a good chuckle when I read that code. I think my co-workers think I'm a little crazy :ugly:

[nivuahc]

That made my brain hurt 

[Lee Mac]

and then there are times when I will write obfuscated code just for the heck of it.

That's just F/M/L soup!

Really though, I had a good chuckle when I read that code. I think my co-workers think I'm a little crazy :ugly:

That made my brain hurt