ποΈ Lesson 5.14 β Organizing LISP Files
Learn how to structure your AutoLISP code for clarity, reusability, and long-term maintenance.
π What Youβll Learn
By the end of this lesson, youβll be able to:
- Structure your AutoLISP code using best practices
- Separate reusable logic from UI and drawing-specific parts
- Use consistent formatting, indentation, and naming conventions
- Write clear comments and in-line documentation
π§ Why It Matters
Well-organized LISP code is easier to debug, extend, and reuse. Whether youβre sharing routines with coworkers or building your own toolkit, clarity and modularity make your work scalable and professional.
π οΈ Tools Youβll Use
Tool / Concept | Purpose |
---|---|
defun | Defines functions |
princ , prompt | Clean output and user messaging |
;;; , ;; , ; | Comment levels for sectioning and explanation |
Modular file structure | Keeps separate files for UI, utilities, and loaders |
π§ Lesson Structure
1οΈβ£ Structure Your Files Logically
A well-structured file might look like this:
;;; greet.lsp
;;; Greeting utility for startup welcome
(defun c:greet ( / )
(alert "Welcome to the drafting environment.")
(princ)
)
π File name matches its main function
π Header comment describes purpose
π princ
keeps the command line clean
2οΈβ£ Use Consistent Commenting
Symbol | Use Case | Example |
---|---|---|
;;; | Section heading | ;;; --- Initialization Functions --- |
;; | Block/function summary | ;; Greets user with alert box |
; | Inline or line explanation | ; Set variable to default |
3οΈβ£ Separate Utilities and Loaders
π Suggested folder and file structure:
/LISP/
βββ utilities/
β βββ math_utils.lsp
β βββ string_utils.lsp
βββ drawing/
β βββ layer_setup.lsp
β βββ titleblock_fill.lsp
βββ startup/
β βββ startup.lsp
βββ main_loader.lsp
n main_loader.lsp
:
(load "utilities/math_utils.lsp")
(load "drawing/layer_setup.lsp")
(load "startup/startup.lsp")
4οΈβ£ Use Meaningful Function Names
Bad Name | Better Name | Why |
---|---|---|
c:doit | c:createlayers | More descriptive |
f | get-drawing-units | Self-documenting |
xx | layerList | Conveys purpose |
β Lesson Checklist
Task | Completed |
---|---|
Created LISP file with clear function definition | β |
Used consistent and appropriate commenting | β |
Organized files into folders based on purpose | β |
Wrote modular functions with self-explanatory names | β |
π Quick Tips
Tip | Why It Helps |
---|---|
Keep one major routine per file | Makes debugging and loading easier |
Always add (princ) at the end | Prevents function echoing at command line |
Use consistent indentation (2-4 spaces) | Improves readability and collaboration |
Group helper functions under comments | Improves section navigation |
π§© Real-World Applications
Scenario | How Structure Helps |
---|---|
Large project with 20+ tools | Organize by function (layer, block, utility) |
Team working on shared routines | Clear comments and names prevent confusion |
Debugging old code | Structure and documentation reduce errors |
π Files and Resources
File / Resource | Description |
---|---|
sample_structured.lsp | A properly structured, commented sample LISP file |
function_naming_cheatsheet.docx | Tips and examples for naming conventions |
lisp_folder_structure_template.docx | Suggested layout for your LISP project folder |
π Review Table
Element | Best Practice | Example |
---|---|---|
defun | Descriptive, with proper parameters | (defun c:createlayers ( / )) |
Comments | Use ;;; headers, ; inline notes | ;;; --- Start of Routine --- |
File naming | Matches purpose | titleblock_fill.lsp |
Folder naming | Follows type or domain | /utilities/ , /drawing/ , /startup/ |