Best practises for code review - aiidateam/aiida-core GitHub Wiki
Standards
Approving changes
Technical facts and data overrule personal preferences
Favor approving a PR once it definitely improves code health overall, even if it isn't perfect
Vigilance
Be responsive to review requests.
AiiDA users who put in the effort of contributing back deserve our attention the most, and timely review of PRs is a big motivator.
Look at every line of code that is being modified
Use a checklist like the one below, especially if you are new to code review
Offer encouragement for things done well, don't just point out mistakes
Fine to mention what could be improved but is not mandatory (prefix such comments with "Nit:" for "nitpick")
Good to share knowledge that helps the submitter improve their understanding of the code (clarify where you do/don't expect action)
Checklist - What to look for
Scope
Are you being asked to review more than 200 lines of code?
Then don't be shy to ask the submitter to split the PR - review effectiveness drops substantially beyond 200 lines of code.
Are there parts of the codebase that have not been modified, but should be adapted to the changes?
Does the code change require an update of the documentation?
Commits
Does the PR consist of self-consistent commits that each tackle a well-defined problem?
If reading the commit messages still leaves you wondering what the commits do, the commit messages should probably be improved!