REVIEW guidelines
This commit is contained in:
@@ -25,3 +25,7 @@ reactive programming (AFRP). Haskell, built with cabal.
|
|||||||
|
|
||||||
- hspec for unit tests, hedgehog for property tests.
|
- hspec for unit tests, hedgehog for property tests.
|
||||||
- Run with `nix develop -c cabal test`.
|
- Run with `nix develop -c cabal test`.
|
||||||
|
|
||||||
|
## Reviewing
|
||||||
|
|
||||||
|
See [[REVIEW.md]]
|
||||||
|
|||||||
@@ -0,0 +1,17 @@
|
|||||||
|
# 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
|
||||||
Reference in New Issue
Block a user