Refactor documentation standards and structure; consolidate clean code principles and service documentation requirements
This commit is contained in:
@@ -6,69 +6,41 @@ alwaysApply: true
|
||||
|
||||
# Code Quality Standards
|
||||
|
||||
When working with code files, follow these standards:
|
||||
|
||||
## Clean Code Documentation
|
||||
Apply the principles detailed in the comprehensive clean code guides:
|
||||
- **Project Overview**: @CLEAN_CODE.md
|
||||
- **API Gateway**: @services/api-gateway/CLEAN_CODE.md
|
||||
- **Service Adapters**: @services/service-adapters/CLEAN_CODE.md
|
||||
- **API Docs**: @services/api-docs/CLEAN_CODE.md
|
||||
- **Frontend**: @frontend/CLEAN_CODE.md
|
||||
|
||||
## 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
|
||||
Follow SOLID principles as detailed in @CLEAN_CODE.md:
|
||||
- **Single Responsibility Principle (SRP)**: Each class/component has one clear purpose
|
||||
- **Open/Closed Principle (OCP)**: Open for extension, closed for modification
|
||||
- **Dependency Inversion Principle (DIP)**: Depend on abstractions, not concretions
|
||||
- **Interface Segregation Principle (ISP)**: Small, focused interfaces
|
||||
|
||||
## 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`)
|
||||
- **Java**: PascalCase classes, camelCase methods, UPPER_SNAKE_CASE constants
|
||||
- **Python**: PascalCase classes, snake_case functions, UPPER_SNAKE_CASE constants
|
||||
- **JavaScript/TypeScript**: PascalCase classes, camelCase functions, UPPER_SNAKE_CASE constants
|
||||
|
||||
## Function Design
|
||||
|
||||
### Small, Focused Functions
|
||||
- Maximum 20-30 lines per function
|
||||
- Single level of abstraction
|
||||
- Clear, descriptive names
|
||||
- Single responsibility
|
||||
|
||||
### Error Handling
|
||||
## 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
|
||||
@@ -76,49 +48,13 @@ alwaysApply: true
|
||||
- [ ] 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
|
||||
- **Unit Tests**: Test business logic, error conditions, edge cases
|
||||
- **Integration Tests**: Test API endpoints, service interactions
|
||||
- **End-to-End Tests**: Test critical user flows, service integration
|
||||
|
||||
## 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
|
||||
- Database optimization with appropriate indexes
|
||||
- Implement caching strategies
|
||||
- Proper resource management
|
||||
- Efficient algorithms
|
||||
Reference in New Issue
Block a user