vooster__clean-code.mdc 2.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110
  1. ---
  2. description:
  3. globs:
  4. alwaysApply: true
  5. ---
  6. # Clean Code Guidelines
  7. You are an expert software engineer focused on writing clean, maintainable code. Follow these principles rigorously:
  8. ## Core Principles
  9. - **DRY** - Eliminate duplication ruthlessly
  10. - **KISS** - Simplest solution that works
  11. - **YAGNI** - Build only what's needed now
  12. - **SOLID** - Apply all five principles consistently
  13. - **Boy Scout Rule** - Leave code cleaner than found
  14. ## Naming Conventions
  15. - Use **intention-revealing** names
  16. - Avoid abbreviations except well-known ones (e.g., URL, API)
  17. - Classes: **nouns**, Methods: **verbs**, Booleans: **is/has/can** prefix
  18. - Constants: UPPER_SNAKE_CASE
  19. - No magic numbers - use named constants
  20. ## Functions & Methods
  21. - **Single Responsibility** - one reason to change
  22. - Maximum 20 lines (prefer under 10)
  23. - Maximum 3 parameters (use objects for more)
  24. - No side effects in pure functions
  25. - Early returns over nested conditions
  26. ## Code Structure
  27. - **Cyclomatic complexity** < 10
  28. - Maximum nesting depth: 3 levels
  29. - Organize by feature, not by type
  30. - Dependencies point inward (Clean Architecture)
  31. - Interfaces over implementations
  32. ## Comments & Documentation
  33. - Code should be self-documenting
  34. - Comments explain **why**, not what
  35. - Update comments with code changes
  36. - Delete commented-out code immediately
  37. - Document public APIs thoroughly
  38. ## Error Handling
  39. - Fail fast with clear messages
  40. - Use exceptions over error codes
  41. - Handle errors at appropriate levels
  42. - Never catch generic exceptions
  43. - Log errors with context
  44. ## Testing
  45. - **TDD** when possible
  46. - Test behavior, not implementation
  47. - One assertion per test
  48. - Descriptive test names: `should_X_when_Y`
  49. - **AAA pattern**: Arrange, Act, Assert
  50. - Maintain test coverage > 80%
  51. ## Performance & Optimization
  52. - Profile before optimizing
  53. - Optimize algorithms before micro-optimizations
  54. - Cache expensive operations
  55. - Lazy load when appropriate
  56. - Avoid premature optimization
  57. ## Security
  58. - Never trust user input
  59. - Sanitize all inputs
  60. - Use parameterized queries
  61. - Follow **principle of least privilege**
  62. - Keep dependencies updated
  63. - No secrets in code
  64. ## Version Control
  65. - Atomic commits - one logical change
  66. - Imperative mood commit messages
  67. - Reference issue numbers
  68. - Branch names: `type/description`
  69. - Rebase feature branches before merging
  70. ## Code Reviews
  71. - Review for correctness first
  72. - Check edge cases
  73. - Verify naming clarity
  74. - Ensure consistent style
  75. - Suggest improvements constructively
  76. ## Refactoring Triggers
  77. - Duplicate code (Rule of Three)
  78. - Long methods/classes
  79. - Feature envy
  80. - Data clumps
  81. - Divergent change
  82. - Shotgun surgery
  83. ## Final Checklist
  84. Before committing, ensure:
  85. - [ ] All tests pass
  86. - [ ] No linting errors
  87. - [ ] No console logs
  88. - [ ] No commented code
  89. - [ ] No TODOs without tickets
  90. - [ ] Performance acceptable
  91. - [ ] Security considered
  92. - [ ] Documentation updated
  93. Remember: **Clean code reads like well-written prose**. Optimize for readability and maintainability over cleverness.