Developer Pre-Submission Checklist

calendarDec 12, 2024 · 3 min read · codereview-knowhow developer pr best-practices  ·
Share on: linkedincopy

Comprehensive checklist for developers before submitting a pull request.

Code Quality

 1□ Code follows project style guide and conventions
 2□ No commented-out code (remove or explain why it's there)
 3□ No debug statements (console.log, print, etc.)
 4□ No TODO comments without issue references
 5□ Variable and function names are clear and descriptive
 6□ Functions are small and do one thing (SRP)
 7□ No magic numbers (use named constants)
 8□ No code duplication (DRY principle)
 9□ Error handling is comprehensive
10□ Edge cases are handled

Tests

1□ All new code has unit tests
2□ All tests pass locally
3□ Test coverage meets project requirements (e.g., >80%)
4□ Integration tests added for new features
5□ Edge cases are tested
6□ Error cases are tested
7□ Tests are readable and maintainable
8□ No flaky tests

Documentation

1□ README updated if needed
2□ API documentation updated
3□ Complex logic has comments explaining "why", not "what"
4□ Public functions have docstrings/JSDoc
5□ CHANGELOG updated (if applicable)
6□ Migration guide included for breaking changes

Security

1□ No sensitive data (passwords, API keys, tokens) in code
2□ Input validation implemented
3□ SQL injection prevention (parameterized queries)
4□ XSS prevention (sanitize user input)
5□ CSRF protection in place
6□ Authentication and authorization checks
7□ Dependencies scanned for vulnerabilities

Performance

1□ No N+1 queries
2□ Database queries are optimized
3□ Caching implemented where appropriate
4□ No unnecessary API calls
5□ Large lists are paginated
6□ Images are optimized
7□ No memory leaks

Git Hygiene

1□ Commits are atomic and logical
2□ Commit messages are clear and descriptive
3□ Branch is up-to-date with main/master
4□ No merge conflicts
5□ No large binary files committed
6□ .gitignore is updated if needed
7□ Sensitive files are not tracked

CI/CD

1□ All CI checks pass (linting, tests, build)
2□ No warnings in build output
3□ Docker image builds successfully (if applicable)
4□ Deployment scripts updated (if needed)

PR Description

1□ Clear title that summarizes the change
2□ Description explains what and why
3□ Links to related issues/tickets
4□ Screenshots/videos for UI changes
5□ Breaking changes are highlighted
6□ Migration steps documented (if needed)
7□ Reviewers are assigned
8□ Labels are added

Before Submitting - Quick Checklist

  1. ✅ Self-review your changes line by line
  2. ✅ Run all tests locally and ensure they pass
  3. ✅ Update documentation (README, API docs, comments)
  4. ✅ Write clear PR description with context and reasoning
  5. ✅ Ensure CI passes before requesting review
  6. ✅ Keep PR small (<400 lines changed if possible)

Author Best Practices

Respond to All Comments

1✅ Acknowledge feedback
2✅ Explain your reasoning if you disagree
3✅ Mark resolved comments
4✅ Thank reviewers for their time

Don't Take It Personally

1✅ Remember: Review is about the code, not you
2✅ Use feedback to improve
3✅ Ask for clarification if needed
4✅ Be open to learning

Keep PRs Small

1✅ Aim for <400 lines changed
2✅ One feature/fix per PR
3✅ Split large changes into multiple PRs
4✅ Use feature flags for incremental rollouts

PR Size Guidelines

Common Mistakes to Avoid

  • ❌ Submitting without self-review
  • ❌ No tests or insufficient test coverage
  • ❌ Vague or missing PR description
  • ❌ Ignoring CI failures
  • ❌ Mixing multiple unrelated changes
  • ❌ Not updating documentation
  • ❌ Leaving debug code or commented code
  • ❌ Hardcoding values that should be configurable

Related Snippets