"Think in properties" | Whenever you see any behavior in code, try to think what properties it is trying to enforce and what properties you'd imagine the code should have that it would break. For example, think in invariants: what should always be true about the contract? | image.png | |
"Ask yourself what's missing" | Checking that some code does what it should is usually relatively easy. It's easy to notice what's wrong, but it's difficult to notice what's missing. Always consider whether any other action should be executed or a check done. | image.png | |
"Audit restrictions" | In some reviews you'll do, you will find a lot of bugs and your client's fixes will be so huge, that it will require you to do a multiple of the work of the audit. Make sure you set the timeline for receiving fixes and that there is an upper limitation on how large the fix diff is. If any requirement is not fulfilled, the review requires a renegotiation. But don't be too strict about it. | image.png | |
"A-, Arch-, Architecture!" | Architecture is the most important thing about the codebase. If the developers thought about it enough, the codebase would be minimal. There will be few places to introduce bugs. If the contracts are large, it usually means that the architecture wasn't well done and it can pay off to look from the higher level: what is wrong with the current design? | image.png |
