HELP ON FORMATTING AUTOLISP

HELP ON FORMATTING AUTOLISP

Satoews
Advocate Advocate
785 Views
7 Replies
Message 1 of 8

HELP ON FORMATTING AUTOLISP

Satoews
Advocate
Advocate

I just created a simple lisp to grab a few types and erase them after I grabbed all the objects i wanted. It fits my needs but one somthing that keeps confusing me is how to format lisps to make them more readable.

 

(defun c:ERS ()
   (COMMAND "ERASE"(SSGET '((0 . "INSERT,AECC_PARCEL_SEGMENT_LABEL")))"")
)

 

with the "" needed at the end of the command i don't think i can do anything more to make this readable. But i wanted to throw it out there and see if i can format it better in the future.

 

thanks in advance!!

 

Shawn

Shawn T
0 Likes
Accepted solutions (2)
786 Views
7 Replies
Replies (7)
Message 2 of 8

ВeekeeCZ
Consultant
Consultant
Accepted solution

you may test ss first.. to prevent command from error.

 

(defun c:ERS ( / ss)
  (if (setq ss (ssget '((0 . "INSERT,AECC_PARCEL_SEGMENT_LABEL"))))
    (command "_.ERASE" ss ""))
  (princ)
)

 

 

 

0 Likes
Message 3 of 8

paullimapa
Mentor
Mentor

You should add comments to your code as a way of reminding yourself as well as explaining to others what you're attempting to do.

Comments are placed after a semicolon ie: 

(defun c:ERS () ;  define a function ERS
 (COMMAND "ERASE"(SSGET '((0 . "INSERT,AECC_PARCEL_SEGMENT_LABEL")))"") ; erase selection set matching insert...
)

 

 

Area Object Link | Attribute Modifier | Dwg Setup | Feet-Inch Calculator
Layer Apps | List on Steroids | VP Zoom Scales | Exchange App Store


Paul Li
IT Specialist
@The Office
Apps & Publications | Video Demos
Message 4 of 8

Kent1Cooper
Consultant
Consultant
Accepted solution

I don't find that particular one lacking in readability, but let's suppose something more complex.  One thing that I think helps with readbility is to use different levels of indentation to create a consistent visual hierarchy.  I break up long functions that way, typically setting everything that is at the same "level" in the hierarchy to the same degree of indentation, and each closing right parenthesis to the same degree of indentation as its opening left parenthesis if it is not on the same line with it.  The examples in the AutoLisp Reference are typically laid out this way.

 

[I like two spaces for the size of a "notch" of indentation, because one space doesn't seem as readably distinct, but you can use what you prefer -- some people use tabs, but I find them more than necessary visually, and they often push a lot of lines long enough that they need to wrap, so they seem too much to me.]

 

For example, if you want to do several things with a selection [a completely unrealistic set of things to do here, perhaps, but only as an illustration]:

 

(defun C:ERS (/ ss ent)
  (if

    (setq ss (ssget '((0 . "INSERT,AECC_PARCEL_SEGMENT_LABEL"))))

      ;; The above 'test expression' is the first argument to the (if) function, and

      ;;   therefore indented one "notch" farther in than the function itself [though

      ;;   in a case like this, with the test expression not too long, I will often include

      ;;   it on the same line as (if)'s opening, and indent only the further arguments].

    (progn ; 'then'

      ;; The above is the second argument to (if), and therefore indented to the same

      ;;   level as other arguments to the same function [except perhaps the test

      ;;   expression if it's on the same line as the opening].

      (setq ent (ssname ss 0)); save first entity in selection in variable

        ;; The above is an argument to (progn), and therefore indented a notch farther.

        ;; I usually put comments on the same line as what they're commenting about if

        ;;   they fit nicely, or if longer, below and indented a notch farther, and if one

        ;;   runs to multiple lines, farther indent the content of lines after the first.

      (setvar 'clayer (cdr (assoc 8 (entget ent)))); set its Layer current

      (command ;; indented the same as other arguments to (progn)

        "_.copy" ent "" "1,0,0" "" ; Copy it 1 unit to the right

          ;; indented a notch farther than (command)'s opening

        "_.erase" ss "" ; remove original selection

      ); command ;; closing the (command) function, so indented same as its opening

    ); progn ;; indented same as (progn)'s opening

    (prompt "\nNothing selected."); 'else'

  ); if ;; indented the same as (if)'s opening

  (princ)
); defun

 

If you wipe out my ;; for-this-Post comments, the visual hierarchy will become even clearer.

 

Another thing that I think helps is to separate items [that are not adjacent to a parenthesis that is part of "their own" function] with spaces, even where it's not actually needed for the code to function.  In your example, I would put spaces in where I have underscores here [of course, it won't work with the underscores, but I don't know a better way to show where I would add spaces]:

 

   (COMMAND "ERASE"_(SSGET '((0 . "INSERT,AECC_PARCEL_SEGMENT_LABEL")))_"")

 

[I don't find any loss of readability from having no space between  (  and  COMMAND  at the beginning of that line, or between  ""  and  )  at the end, but you will see spaces used in such places sometimes, too.]

 

Those added spaces aren't all that important to readability in this case, but there are situations where that kind of difference does make more of a difference.  For example, my line about moving the first entity in the selection over 1 unit to the right could be done as follows, if all you want is for it to function, but I find it harder to read this way:

 

        "_.copy"ent"""1,0,0""";Copy it 1 unit to the right

Kent Cooper, AIA
0 Likes
Message 5 of 8

ВeekeeCZ
Consultant
Consultant

I think the good readability will help a lot if you do not use all CAPITAL LETTERS. People are not accustomed to it and when you have read the entire page of code ... it's not very pleasant. (then... I rather convert  the entire code to a low-case letters - CTRL+U)

Message 6 of 8

BeKirra
Advisor
Advisor

Agree with BeeKeeCZ.

Keeping your code in lower case, especially with those function names and system variable names, etc, will make your code more readable when you using "VLIDE" (Visual Lisp Editor) or other text editor (e.g. Notepad++).

 

HTH

Please mark "Accept as Solution" and "Like" if my reply resolves the issue and it will help when others need helps.
= ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ = ♪ = ♫ =
A circle is the locus of a cursor, starting and ending at the same point on a plane in model space or in layout such that its distance from a given coordinates (X,Y) is always constant.
X² + Y² = C²
Message 7 of 8

martti.halminen
Collaborator
Collaborator

 

The indentation style you show is often seen in AutoLISP, but  the mainstream Lisp culture (Common Lisp, Scheme) considers that too sparse.

 

Professional Lisp programmers read the program structure by indentation, but as the editor counts closing parentheses, there is no need to separate those each on its own line. So your example formatted in the way a CL programmer would do this:

 

(defun C:ERS (/ ss ent)
  (if (setq ss (ssget '((0 . "INSERT,AECC_PARCEL_SEGMENT_LABEL"))))
      (progn 
        (setq ent (ssname ss 0))
        (setvar 'clayer (cdr (assoc 8 (entget ent))))
        (command 
         "_.copy" ent "" "1,0,0" "" 
         "_.erase" ss ""))
      (prompt "\nNothing selected."))
  (princ))

Regarding comments: no need to comment language primitives or generally what is being done (unless it is some unreadable thicket better hidden inside a function).

The comments should be more about why something is being done, or about other information not immediately visible in the program text.

 

-- 

Message 8 of 8

Satoews
Advocate
Advocate

Thanks for all the feedback! This makes formatting a lot more clear to me.

 

Thanks!

 

Shawn Toews

Shawn T
0 Likes