|
| 1 | +--- |
| 2 | +name: refactor-method-complexity-reduce |
| 3 | +description: Refactor given method `${input:methodName}` to reduce its cognitive complexity to `${input:complexityThreshold}` or below, by extracting helper methods. |
| 4 | +argument-hint: methodName=..., complexityThreshold=15 |
| 5 | +agent: agent |
| 6 | +model: Auto (copilot) |
| 7 | +tools: ['search/changes', 'search/codebase', 'edit/editFiles', 'read/problems', 'execute/runTests'] |
| 8 | +--- |
| 9 | + |
| 10 | +# Refactor Method to Reduce Cognitive Complexity |
| 11 | + |
| 12 | +## Objective |
| 13 | +Refactor the method `${input:methodName}`, to reduce its cognitive complexity to `${input:complexityThreshold}` or below, by extracting logic into focused helper methods. |
| 14 | + |
| 15 | +## Instructions |
| 16 | + |
| 17 | +1. **Analyze the current method** to identify sources of cognitive complexity: |
| 18 | + - Nested conditional statements |
| 19 | + - Multiple if-else or switch chains |
| 20 | + - Repeated code blocks |
| 21 | + - Multiple loops with conditions |
| 22 | + - Complex boolean expressions |
| 23 | + |
| 24 | +2. **Identify extraction opportunities**: |
| 25 | + - Validation logic that can be extracted into a separate method |
| 26 | + - Type-specific or case-specific processing that repeats |
| 27 | + - Complex transformations or calculations |
| 28 | + - Common patterns that appear multiple times |
| 29 | + |
| 30 | +3. **Extract focused helper methods**: |
| 31 | + - Each helper should have a single, clear responsibility |
| 32 | + - Extract validation into separate `Validate*` methods |
| 33 | + - Extract type-specific logic into handler methods |
| 34 | + - Create utility methods for common operations |
| 35 | + - Use appropriate access levels (static, private, async) |
| 36 | + |
| 37 | +4. **Simplify the main method**: |
| 38 | + - Reduce nesting depth |
| 39 | + - Replace massive if-else chains with smaller orchestrated calls |
| 40 | + - Use switch statements where appropriate for cleaner dispatch |
| 41 | + - Ensure the main method reads as a high-level flow |
| 42 | + |
| 43 | +5. **Preserve functionality**: |
| 44 | + - Maintain the same input/output behavior |
| 45 | + - Keep all validation and error handling |
| 46 | + - Preserve exception types and error messages |
| 47 | + - Ensure all parameters are properly passed to helpers |
| 48 | + |
| 49 | +6. **Best practices**: |
| 50 | + - Make helper methods static when they don't need instance state |
| 51 | + - Use null checks and guard clauses early |
| 52 | + - Avoid creating unnecessary local variables |
| 53 | + - Consider using tuples for multiple return values |
| 54 | + - Group related helper methods together |
| 55 | + |
| 56 | +## Implementation Approach |
| 57 | + |
| 58 | +- Extract helper methods before refactoring the main flow |
| 59 | +- Test incrementally to ensure no regressions |
| 60 | +- Use meaningful names that describe the extracted responsibility |
| 61 | +- Keep extracted methods close to where they're used |
| 62 | +- Consider making repeated code patterns into generic methods |
| 63 | + |
| 64 | +## Result |
| 65 | + |
| 66 | +The refactored method should: |
| 67 | +- Have cognitive complexity reduced to the target threshold of `${input:complexityThreshold}` or below |
| 68 | +- Be more readable and maintainable |
| 69 | +- Have clear separation of concerns |
| 70 | +- Be easier to test and debug |
| 71 | +- Retain all original functionality |
| 72 | + |
| 73 | +## Testing and Validation |
| 74 | + |
| 75 | +**CRITICAL: After completing the refactoring, you MUST:** |
| 76 | + |
| 77 | +1. **Run all existing tests** related to the refactored method and its surrounding functionality |
| 78 | +2. **MANDATORY: Explicitly verify test results show "failed=0"** |
| 79 | + - **NEVER assume tests passed** - always examine the actual test output |
| 80 | + - Search for the summary line containing pass/fail counts (e.g., "passed=X failed=Y") |
| 81 | + - **If the summary shows any number other than "failed=0", tests have FAILED** |
| 82 | + - If test output is in a file, read the entire file to locate and verify the failure count |
| 83 | + - Running tests is NOT the same as verifying tests passed |
| 84 | + - **Do not proceed** until you have explicitly confirmed zero failures |
| 85 | +3. **If any tests fail (failed > 0):** |
| 86 | + - State clearly how many tests failed |
| 87 | + - Analyze each failure to understand what functionality was broken |
| 88 | + - Common causes: null handling, empty collection checks, condition logic errors |
| 89 | + - Identify the root cause in the refactored code |
| 90 | + - Correct the refactored code to restore the original behavior |
| 91 | + - Re-run tests and verify "failed=0" in the output |
| 92 | + - Repeat until all tests pass (failed=0) |
| 93 | +4. **Verify compilation** - Ensure there are no compilation errors |
| 94 | +5. **Check cognitive complexity** - Confirm the metric is at or below the target threshold of `${input:complexityThreshold}` |
| 95 | + |
| 96 | +## Confirmation Checklist |
| 97 | +- [ ] Code compiles without errors |
| 98 | +- [ ] **Test results explicitly state "failed=0"** (verified by reading the output) |
| 99 | +- [ ] All test failures analyzed and corrected (if any occurred) |
| 100 | +- [ ] Cognitive complexity is at or below the target threshold of `${input:complexityThreshold}` |
| 101 | +- [ ] All original functionality is preserved |
| 102 | +- [ ] Code follows project conventions and standards |
0 commit comments