|
| 1 | +# GitHub Copilot Instructions |
| 2 | + |
| 3 | +## Code Review Guidelines |
| 4 | + |
| 5 | +### Review Focus |
| 6 | +- **Do not repeat or paraphrase the PR description** |
| 7 | +- Only highlight changes or notable information that was omitted from the description |
| 8 | +- Focus on code quality, potential issues, and improvements not mentioned in the PR |
| 9 | + |
| 10 | +### PHP Version and Type Requirements |
| 11 | +- Code must support **PHP 8.1 and newer** |
| 12 | +- Use **full type declarations** wherever possible |
| 13 | +- Leverage PHP 8.1+ features when appropriate (enums, readonly properties, intersection types, etc.) |
| 14 | +- Use **PHPDoc blocks** to supplement native types where PHP limitations exist: |
| 15 | + - Generics: `@template T`, `@param Collection<T>`, `@return T` |
| 16 | + - Union types for complex scenarios |
| 17 | + - Array shapes: `@param array{name: string, age: int}` |
| 18 | + - More specific types than native PHP allows |
| 19 | + |
| 20 | +### Code Quality Standards |
| 21 | +- Ensure all public methods have complete type hints |
| 22 | +- Private/protected methods should also be fully typed |
| 23 | +- Use strict scalar type declarations (`declare(strict_types=1)`) |
| 24 | +- Prefer constructor property promotion when applicable |
| 25 | +- Use named arguments for better readability in complex method calls |
| 26 | + |
| 27 | +### MongoDB Library Specific |
| 28 | +- Check for proper error handling patterns |
| 29 | +- Ensure BSON type handling is correct |
| 30 | +- Verify connection pool and client usage follows best practices |
| 31 | +- Look for potential performance implications in database operations |
| 32 | +- Ensure proper use of type maps and codecs |
| 33 | + |
| 34 | +### What to Flag in Reviews |
| 35 | +- Missing type declarations that could be added |
| 36 | +- Opportunities to use newer PHP features |
| 37 | +- Code that might not work with the minimum PHP 8.1 requirement |
| 38 | +- Missing PHPDoc for complex types or generics |
| 39 | +- Inconsistent coding standards |
| 40 | +- Potential performance or security issues not mentioned in PR description |
| 41 | +- Breaking changes that weren't highlighted |
| 42 | +- Documentation that needs updating due to code changes |
| 43 | + |
| 44 | +### What NOT to Comment On |
| 45 | +- Changes that are clearly explained in the PR description |
| 46 | +- Style preferences that are already covered by existing linting tools |
| 47 | +- Minor formatting issues that automated tools should catch |
0 commit comments