|
| 1 | +# Code Review Guidelines for OpenSearch SQL |
| 2 | + |
| 3 | +This document provides guidelines for code reviews in the OpenSearch SQL project. These guidelines are used by CodeRabbit AI for automated code reviews and serve as a reference for human reviewers. |
| 4 | + |
| 5 | +## Core Review Principles |
| 6 | + |
| 7 | +### Code Quality |
| 8 | +- **Simplicity First**: Prefer simpler solutions unless there's significant functional or performance degradation |
| 9 | +- **Self-Documenting Code**: Code should be clear through naming and structure, not comments |
| 10 | +- **No Redundant Comments**: Avoid comments that merely restate what the code does |
| 11 | +- **Concise Implementation**: Keep code, docs, and notes short and focused on essentials |
| 12 | + |
| 13 | +### Java Standards |
| 14 | +- **Naming Conventions**: |
| 15 | + - Classes: `PascalCase` (e.g., `QueryExecutor`) |
| 16 | + - Methods/Variables: `camelCase` (e.g., `executeQuery`) |
| 17 | + - Constants: `UPPER_SNAKE_CASE` (e.g., `MAX_RETRY_COUNT`) |
| 18 | +- **Method Size**: Keep methods under 20 lines with single responsibility |
| 19 | +- **JavaDoc Required**: All public classes and methods must have proper JavaDoc |
| 20 | +- **Error Handling**: Use specific exception types with meaningful messages |
| 21 | +- **Null Safety**: Prefer `Optional<T>` for nullable returns |
| 22 | + |
| 23 | +### Testing Requirements |
| 24 | +- **Test Coverage**: All new business logic requires unit tests |
| 25 | +- **Integration Tests**: End-to-end scenarios need integration tests in `integ-test/` module |
| 26 | +- **Test Execution**: Verify changes with `./gradlew :integ-test:integTest` |
| 27 | +- **No Failing Tests**: All tests must pass before merge; fix or ask for guidance if blocked |
| 28 | + |
| 29 | +### Code Organization |
| 30 | +- **Single Responsibility**: Each class should have one clear purpose |
| 31 | +- **Package Structure**: Follow existing module organization (core, ppl, sql, opensearch) |
| 32 | +- **Separation of Concerns**: Keep parsing, execution, and storage logic separate |
| 33 | +- **Composition Over Inheritance**: Prefer composition for code reuse |
| 34 | + |
| 35 | +### Performance & Security |
| 36 | +- **Efficient Loops**: Avoid unnecessary object creation in loops |
| 37 | +- **String Handling**: Use `StringBuilder` for concatenation in loops |
| 38 | +- **Input Validation**: Validate all user inputs, especially queries |
| 39 | +- **Logging Safety**: Sanitize data before logging to prevent injection |
| 40 | +- **Resource Management**: Use try-with-resources for proper cleanup |
| 41 | + |
| 42 | +## Review Focus Areas |
| 43 | + |
| 44 | +### What to Check |
| 45 | +1. **Code Clarity**: Is the code self-explanatory? |
| 46 | +2. **Test Coverage**: Are there adequate tests? |
| 47 | +3. **Error Handling**: Are errors handled appropriately? |
| 48 | +4. **Documentation**: Is JavaDoc complete and accurate? |
| 49 | +5. **Performance**: Are there obvious performance issues? |
| 50 | +6. **Security**: Are inputs validated and sanitized? |
| 51 | + |
| 52 | +### What to Flag |
| 53 | +- Redundant or obvious comments |
| 54 | +- Methods longer than 20 lines |
| 55 | +- Missing JavaDoc on public APIs |
| 56 | +- Generic exception handling |
| 57 | +- Unused imports or dead code |
| 58 | +- Hard-coded values that should be constants |
| 59 | +- Missing or inadequate test coverage |
| 60 | + |
| 61 | +### What to Encourage |
| 62 | +- Clear, descriptive naming |
| 63 | +- Proper use of Java idioms |
| 64 | +- Comprehensive test coverage |
| 65 | +- Meaningful error messages |
| 66 | +- Efficient algorithms and data structures |
| 67 | +- Security-conscious coding practices |
| 68 | + |
| 69 | +## Project-Specific Guidelines |
| 70 | + |
| 71 | +### OpenSearch SQL Context |
| 72 | +- **JDK 21**: Required for development |
| 73 | +- **Java 11 Compatibility**: Maintain when possible for OpenSearch 2.x |
| 74 | +- **Module Structure**: Respect existing module boundaries |
| 75 | +- **Integration Tests**: Use `./gradlew :integ-test:integTest` for testing |
| 76 | +- **Test Naming**: `*IT.java` for integration tests, `*Test.java` for unit tests |
| 77 | + |
| 78 | +### PPL Parser Changes |
| 79 | +- Test new grammar rules with positive and negative cases |
| 80 | +- Verify AST generation for new syntax |
| 81 | +- Include edge cases and boundary conditions |
| 82 | +- Update corresponding AST builder classes |
| 83 | + |
| 84 | +### Calcite Integration |
| 85 | +- If the PR is for PPL command, refer docs/dev/ppl-commands.md and verify the PR satisfy the checklist. |
| 86 | +- Follow existing patterns in `CalciteRelNodeVisitor` and `CalciteRexNodeVisitor` |
| 87 | +- Test SQL generation and optimization paths |
| 88 | +- Document Calcite-specific workarounds |
0 commit comments