Critique principles for maintainable, readable code
Critiques code against maintainability principles and suggests improvements.
/plugin marketplace add nyldn/claude-octopus/plugin install claude-octopus@nyldn-pluginsCode MUST adhere to these maintainability requirements:
Single Responsibility - Functions and classes do ONE thing. Keep them focused and small.
DRY (Don't Repeat Yourself) - Extract common logic into reusable functions. Avoid copy-paste.
Separation of Concerns - Keep business logic, data access, and presentation separate.
Clear Naming - Variables, functions, and classes describe their purpose. Avoid abbreviations.
No Magic Numbers - Constants are named and explained. Avoid hardcoded values.
Consistent Style - Follow project conventions. Use consistent formatting and patterns.
Explicit Error Handling - All errors are caught and handled appropriately. No silent failures.
Meaningful Error Messages - Errors include context for debugging. Log relevant details.
Graceful Degradation - Handle edge cases. Provide fallbacks where appropriate.
Testability - Code is unit-testable. Dependencies are injectable. Pure functions preferred.
Self-Documenting Code - Code is readable without comments. Complex logic has explanations.
API Documentation - Public APIs have clear documentation. Include examples.
Loose Coupling - Minimize dependencies between modules. Use interfaces/abstractions.
High Cohesion - Related functionality is grouped together. Modules have clear boundaries.
YAGNI - Don't build for hypothetical future requirements. Solve current problems.
When reviewing code, verify:
Deeply analyzes existing codebase features by tracing execution paths, mapping architecture layers, understanding patterns and abstractions, and documenting dependencies to inform new development