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