Description
Design
-
Balance between runtime gas and bytecode size.
- Strong preference for expressions that can be adaptively evaluated on compile time depending on the optimizer runs, which can be tweaked by users.
-
Reduce reverts if possible.
-
Consider returning special values for edge cases. Let users decide on how they want to handle it.
-
Reverts require branching, which makes functions non-inlinable.
-
-
Best is an elegant API that is safe, intuitive, and saves gas.
-
Do not over modularize.
-
Libraries should be as independent from each other as possible.
-
If you want a new feature, do give a convincing, well-designed use case for the feature.
- Great low-level library, but bad high level approach = bad code.
-
Suppose we have two standard-conforming implementations:
A: more gas efficient, but harder to use.
B: less gas efficient, but easier to use.
We will prefer A.
-
Optimize for performance and flexibility for experts.
Safety and Testing
-
Mask inputs that are less than 256 in bit width.
-
Brutalize memory in tests if the code allocates memory.
-
Brutalize upper unused bits of inputs if possible.
-
Test with paranoia. The code is only as good as the tests.
-
Prefer a few general concise fuzz tests that cover every possibility, over many verbose small unit tests that each fail only for specific cases. General fuzz tests help catch the unknown unknowns, the blind spots. Safety first.
-
Test until you are absolutely certain of correctness and safety, even in adversarial conditions.