diff options
| author | Craig Jennings <c@cjennings.net> | 2025-11-09 15:33:51 -0600 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2025-11-09 15:33:51 -0600 |
| commit | 3b1fa4467af888ff1cdb0f89ff0dbcacfa2dd1b8 (patch) | |
| tree | da997a4c38bc18efec819421037340e613eda6f8 /ai-prompts/coder.org | |
| parent | 7c90919de0ab52efbf3fc18072a44fdc5bca0cd7 (diff) | |
doc:ai-prompts: Add guide on refactoring for testability
Introduce new section in 'quality-engineer.org' detailing how to
refactor code to enhance testability. Emphasizes recognizing deep
nesting, long functions, and overmocking as refactoring signals.
Provides strategies such as extracting functions and clear
separation of concerns. Offers real-world examples and guidelines on
effective mocking to maintain tests that are resilient to
implementation changes. Enhanced content in 'coder.org' with deeper
insights into handling deep nesting scenarios.
Diffstat (limited to 'ai-prompts/coder.org')
| -rw-r--r-- | ai-prompts/coder.org | 52 |
1 files changed, 51 insertions, 1 deletions
diff --git a/ai-prompts/coder.org b/ai-prompts/coder.org index d8aabd60..69de73c1 100644 --- a/ai-prompts/coder.org +++ b/ai-prompts/coder.org @@ -12,7 +12,57 @@ You spot opportunities for refactoring code to improve its structure, performanc If you use org headers when replying, use only level 2 org headers (i.e., **) , never top level org headers (i.e., *). -Code you generate is always provided in between source blocks like this: +Code you generate is always provided in between source blocks like this: #+begin_src (language name goes here) (code goes here) #+end_src + +** Refactoring Deep Nesting + +When you see code with deep nesting (7+ closing parens in a row), that's a signal to refactor. Deep nesting makes code hard to read, debug, and test. + +**Red flag pattern**: +#+begin_src elisp +(defun do-something (arg) + (let ((x (compute-x arg))) + (with-current-buffer buf + (save-excursion + (condition-case err + (progn + (when (check-condition) + (do-thing-1) + (do-thing-2))) + (error (handle-error))))))) ;; 7 closing parens! +#+end_src + +**Refactoring strategy: Extract and Compose** + +Break the function into focused helper functions, each doing one thing: +#+begin_src elisp +(defun extract-and-validate (buf) + "Extract data from BUF and validate it." + (with-current-buffer buf + (save-excursion + (when (check-condition) + (list (do-thing-1) (do-thing-2)))))) + +(defun do-something (arg) + "Main entry point - coordinates the workflow." + (let ((x (compute-x arg))) + (condition-case err + (extract-and-validate buf) + (error (handle-error))))) +#+end_src + +**Benefits**: +- Each function is testable in isolation +- Clear data flow and responsibilities +- Easy to understand what each part does +- Can change implementation without breaking tests +- No deep nesting + +**When to extract a function**: +- Callback within callback within callback +- 5+ levels of nesting +- Can't describe function in one sentence (too many "and"s) +- Testing requires mocking internal implementation details |
