A hardly exhaustive collection of considerations when peer-reviewing software.
Clean, merge-ready pull requests:
- implement relevant specification(s)
- anticipate and address failure modes
- avoid (or adequately justifies) obvious performance issues
- provide appropriate user feedback
- expose logs, errors, and other runtime debugging details as needed
- secure behaviors described in relevant specification(s)
- test public interfaces
- cover anticipated failure modes
- benchmark recognized performance issues
- run green
- embrace style and patterns established by the project, team, and community
- consume existing libraries, methods, and types
- use suggestive names for functions, variables, and classes
- document public interfaces as appropriate
- remove (or adequately support) TODOs, legacy code, and hacks
- bound and sanitize inputs
- sanitize outputs, including analytics and logs
- recognize and address common vulnerabilities (SQL injection, XSS, buffer overruns, etc)
- isolate platform-/environment-specific functionality
- provide clear, useful commit messages
- reference external issues, tickets, and bugs where they exist
- use incremental, atomic commits
- avoid binaries, logs, local configurations, environment-specific files, plaintext secrets, or other unwanted artifacts
MIT licensed - fork, contribute, and enjoy!