Code Review Guidelines

Each MR should be focused, changing only one concept at a time
Keep MRs small - aim for under 500 lines of diff. There can be some wiggle room for cases that are hard to split
When reviewing code, check for test coverage and suggest tests if missing
Go through tests and think hard to see if any unit tests or group of unit tests can be replaced with a property test
When suggesting a property test, consider cases that the property needs to falsify and whether it needs its own generator
Business logic stays pure

Comments

Less is more
If there's comments for a function, verify they're proper haddock style
If there's comments for a function, they must only be about the contract and use instructions
If there's comments for implementation, they should only be for exceptional cases, cases where the reader would question why something is implemented like that
Comment style should follow minimalistic writing style