124 lines
3.2 KiB
Plaintext
124 lines
3.2 KiB
Plaintext
---
|
|
description: Code quality standards and clean code principles
|
|
globs: ["**/*.java", "**/*.py", "**/*.js", "**/*.jsx", "**/*.ts", "**/*.tsx"]
|
|
alwaysApply: true
|
|
---
|
|
|
|
# Code Quality Standards
|
|
|
|
## Clean Code Principles
|
|
|
|
### Single Responsibility Principle (SRP)
|
|
- Each class/component has one clear purpose
|
|
- Each function/method does one thing
|
|
- Clear separation of concerns
|
|
- Minimal coupling between components
|
|
|
|
### Open/Closed Principle (OCP)
|
|
- Open for extension, closed for modification
|
|
- Use interfaces and abstractions
|
|
- Plugin architecture where appropriate
|
|
- Configuration-driven behavior
|
|
|
|
### Dependency Inversion Principle (DIP)
|
|
- Depend on abstractions, not concretions
|
|
- Use dependency injection
|
|
- Interface-based design
|
|
- Inversion of control
|
|
|
|
### Interface Segregation Principle (ISP)
|
|
- Small, focused interfaces
|
|
- Clients should not depend on unused methods
|
|
- Specific-purpose modules
|
|
- Clear API boundaries
|
|
|
|
## Naming Conventions
|
|
|
|
### Java (Spring Boot)
|
|
- Classes: PascalCase (e.g., `DashboardController`)
|
|
- Methods: camelCase (e.g., `getAllDashboards`)
|
|
- Variables: camelCase (e.g., `dashboardRepository`)
|
|
- Constants: UPPER_SNAKE_CASE (e.g., `API_VERSION`)
|
|
|
|
### Python (FastAPI)
|
|
- Classes: PascalCase (e.g., `ServiceStatus`)
|
|
- Functions: snake_case (e.g., `get_home_assistant_entities`)
|
|
- Variables: snake_case (e.g., `service_config`)
|
|
- Constants: UPPER_SNAKE_CASE (e.g., `SERVICES`)
|
|
|
|
### JavaScript/TypeScript (Node.js, React)
|
|
- Classes: PascalCase (e.g., `DashboardComponent`)
|
|
- Functions: camelCase (e.g., `fetchServiceSpec`)
|
|
- Variables: camelCase (e.g., `serviceStatus`)
|
|
- Constants: UPPER_SNAKE_CASE (e.g., `API_CONFIG`)
|
|
|
|
## Function Design
|
|
|
|
### Small, Focused Functions
|
|
- Maximum 20-30 lines per function
|
|
- Single level of abstraction
|
|
- Clear, descriptive names
|
|
- Single responsibility
|
|
|
|
### Error Handling
|
|
- Consistent error responses
|
|
- Proper exception handling
|
|
- User-friendly error messages
|
|
- Logging for debugging
|
|
|
|
## Code Review Checklist
|
|
|
|
### Before Merging
|
|
- [ ] All new code follows naming conventions
|
|
- [ ] Error handling is implemented
|
|
- [ ] Input validation is present
|
|
- [ ] Documentation is updated
|
|
- [ ] Tests are written and passing
|
|
- [ ] Clean code principles are followed
|
|
|
|
### Documentation Review
|
|
- [ ] README files are comprehensive
|
|
- [ ] Clean code documentation is complete
|
|
- [ ] Project structure is updated
|
|
- [ ] Progress tracking is current
|
|
- [ ] Links are working and relevant
|
|
|
|
## Testing Requirements
|
|
|
|
### Unit Tests
|
|
- Test business logic
|
|
- Test error conditions
|
|
- Test edge cases
|
|
- Maintain high coverage
|
|
|
|
### Integration Tests
|
|
- Test API endpoints
|
|
- Test service interactions
|
|
- Test error scenarios
|
|
- Test configuration
|
|
|
|
### End-to-End Tests
|
|
- Test critical user flows
|
|
- Test service integration
|
|
- Test error recovery
|
|
- Test performance
|
|
|
|
## Performance Guidelines
|
|
|
|
### Database Optimization
|
|
- Use appropriate indexes
|
|
- Implement connection pooling
|
|
- Use lazy loading where appropriate
|
|
- Optimize queries
|
|
|
|
### Caching
|
|
- Implement appropriate caching
|
|
- Use Redis for distributed caching
|
|
- Cache frequently accessed data
|
|
- Implement cache invalidation
|
|
|
|
### Resource Management
|
|
- Proper cleanup of resources
|
|
- Memory leak prevention
|
|
- Connection pooling
|
|
- Efficient algorithms |