Skip to content

Commit

Permalink
Add PR review checklist
Browse files Browse the repository at this point in the history
  • Loading branch information
Jatin-1602 committed Jan 23, 2025
1 parent baab9a6 commit e0f4329
Showing 1 changed file with 65 additions and 0 deletions.
65 changes: 65 additions & 0 deletions tech-standards/standared-PR-review-checklist.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# Standard PR Review Checklist

## PR Meta Information

- **PR Title**: Ensure the PR title is clear, concise, and adheres to the project's naming standards (e.g., `[Feature] Add X`, `[Bugfix] Fix Y`, `[Refactor] Z`).
- **Description**: Include a detailed description explaining:
- What the PR does.
- Why the changes are necessary.
- Links to related issues, tickets, or tasks (if applicable).
- **Checklist in Description (Optional)**: Include a checklist of tasks completed (if the project uses task checklists).
- **Reviewer Assignment**: The PR must be assigned to at least one reviewer.
- **Labels/Tags (Optional)**: Ensure the PR has appropriate labels/tags (e.g., `Bugfix`, `Feature`, `Documentation`).

## Code Changes

- **Scope of Changes**:
- PR should contain changes related to only one feature, bugfix, or task.
- Avoid mixing multiple unrelated changes in one PR.
- **Clean Code**:
- Code should follow the project's coding standards (naming conventions, indentation, spacing).
- Ensure proper formatting (auto-format code if tools are available).
- **No Repetition**: Avoid duplicate code; refactor into reusable functions or components where possible.
- **No Hardcoded Values**: Replace hardcoded values with constants, environment variables, or configurations.

## Quality and Best Practices

- **Tests**:
- Ensure unit tests or integration tests are added/updated for the feature or bugfix.
- Run all tests and confirm they pass locally.
- **Linting and Static Analysis**:
- Code should pass all linting checks (e.g., ESLint, Flake8, etc.).
- Resolve any warnings or errors flagged by static analysis tools.
- **Error Handling**: Ensure proper error handling is implemented (avoid swallowing errors silently).
- **Performance Considerations**: Check for code efficiency (e.g., avoid unnecessary loops, database queries, or API calls).

## Compliance

- **CI/CD Pipelines**:
- Ensure all CI pipelines (builds, tests, deployments) pass successfully.
- Attach a CI screenshot if the pipelines aren't integrated into the PR system.
- **Security**:
- Verify no sensitive information (API keys, passwords, etc.) is exposed in the code or configuration.
- Check for usage of secure methods and libraries.
- **Backward Compatibility**: Ensure the changes don't break existing functionality or introduce regressions.

## Documentation and UI

- **Documentation (Optional)**: Update relevant documentation (e.g., README, API documentation, comments) for new features or changes.
- **Screenshots/Videos (Optional)**:
- Add screenshots or video recordings for UI changes (if applicable).
- Ensure the UI matches the design and is responsive on different screen sizes.

## Miscellaneous

- **Dead Code**: Remove any unused code, variables, or imports.
- **Debugging Artifacts**: Ensure no debugging code (e.g., `console.log`, `print`) is left in the codebase.
- **Dependencies (Optional)**:
- Verify no unnecessary or outdated dependencies are introduced.
- Lock file changes (e.g., `package-lock.json`, `requirements.txt`) should be reviewed.

## Final Checks

- **Self-Review**: The developer submitting the PR must perform a thorough self-review before assigning it to a reviewer.
- **Cross-Environment Testing (Optional)**: Confirm the changes work in multiple environments (e.g., dev, staging, production).
- **Feature Flags (Optional)**: Ensure new features are behind feature flags if they are not fully ready for release.

0 comments on commit e0f4329

Please sign in to comment.