🗃️ 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/ |