AutoLISP to Visual LISP
    Kevin Standiford, Autodesk Press, ISBN 0-7668-1517
  AutoLISP: Programming for Productivity,
    William Kramer, Autodesk Press, ISBN 0-8273-5832-6
  Essential AutoLISP,
    Roy Harkow, Springer-Verlag, ISBN 0-387-94571-7
  AutoLISP in Plain English, A Practical Guide for Non-Programmers,
    George O. Head, Ventana Press, ISBN 1-566-04140-6
  AutoLISP Reference Manual
    Autodesk Press.
    Up to R12 there was a separate AutoLISP Reference book. Then AutoLISP
    became a part of the Customization Guide for R13. From R14 on this
    guide is compiled as Winhelp.
  Maximizing AutoLISP
    Rusty Gesner, Tony and Mark Middlebrook, Tony Tanzillo.
    A new Maximizing AutoLISP R13/R14 will be published hopefully
    sooner or later. But the R12 book is still worth buying, though it's
    difficult to find. More at http://www.group-a.com/~rusty

  There is a lot more AutoLISP books around.
  Recommended general LISP books (not AutoLISP!) are:
  ANSI Common Lisp, (Common Lisp primer)
    Paul Graham, Prentice Hall, ISBN 0-13-370875-6
  Structure and Interpretation of Computer Programs, (high-level Scheme)
    H.Abelson, GJ. Sussman, J. Sussman, MIT Press, ISBN 0-262-01153-0
    "This undoubtedly one of the best general computer books ever written."
  LISP, 3rd Edition,
    Patrick Henry Winston and Berthold Klaus Paul Horn,
    Addison-Wesley Publishing Company, ISBN 0-201-08319-1
  Looking at LISP,
    Tony Hasemer, Addison-Wesley Publishing Company, ISBN 0-201-12080-1


[2.1] Online AutoLISP documents, Winhelp [deleted]

[2.2] AutoLISP Coding Style

  Most of the samples being published by magazines or at various
  websites are written badly making the AutoLISP learning process even
  harder for newbies. LISP is hard to read anyway because of it's
  briefness and countless parentheses. Everybody is enforced to
  write clear, readable code. Autodesk's samples are quite well written
  but sometimes overdone. :)

  Automatic pretty printers, or so called beautifiers (see
  [6.3]) automatically format the code according to some kind of standard.

  On the R12 CD-ROM in the SDK2 ACG.DOC or at
  http://xarch.tu-graz.ac.at/autocad/docs/acg.txt is an excellent
  Autodesk documentation about coding, commenting and intentation standards
  to keep lisp code readable.

  The most important points are:
  * Comment your code using ";;;" at row 1, ";;" inside the code
    (indented) and ";" for trailing comments (at row 39)
  * Follow the indenting standards as given by the pretty printers
    to be able to write better structured code, which is more readable.
      esp. for SETQ, DEFUN, IF, COND, PROGN
  * Try to avoid global variables. If you use them (for efficiency), to
    clarify, place asterics around them in uppercase, i.e: *GLOBAL*
  * Don't forget to localize your variables (behind "/" in the DEFUN
    parameter list). Only for debugging purposes you may want to
    undefine them temporarly.
  * Name protection: Since AutoLISP provides no protected name space,
    it's easy to overwrite even system functions. Use unique
    short prefixes at least when you publish or give away your code.
    I use UR- for functions and UR: for variables. The ADGE and Autodesk
    forces even 4 letter prefixes. Then your names are safe
    from being overwritten by other kamikaze functions.
  * Always use the leading underscore with any string (commands and
    options) given to COMMAND and OSNAP. There are even enough
    commercial programs which do not work on international versions.
    (command "_PEDIT" ss "_J") is better than (command "PEDIT" ss "J")
  * Don't do too much SETQ's: LISP was originally a functional language,
    without any variables. There are enough constructs which work
    efficiently with lists without the need of storing values
    intermediatly in symbols. (see code samples [22]...)
    But for readability and debugging purposes you should always set
    symbols.
  * An old LISP rule is: Any good function is not longer than 6 lines :)
    (LISP is the second oldest computer language, invented by John
    McCarthy at the MIT in 1958)
  * Prefer CONS over APPEND: three CONS and one REVERSE is better than
    one APPEND. For tricks with APPEND (omitting NIL) see esp. Serge's
    samples: i.e. REMOVE at [11] or the style comparison at [23.1])
  * Try to use English symbols and comments
  * Don't use T, MIN, MAX or LAST as symbols! These are system functions!