📌 Contribution guidelines #19
Description
Most of the stuff here are similar to solmate's.
Points that are specific to solady are marked with a ♡.
Emoji key for Issues and PRs
Format: <emoji><space><Title>
| Type | Emoji |
|---|---|
| readme/docs | 📝 |
| new feature | ✨ |
| refactor/cleanup | ♻️ |
| nit | 🥢 |
| security fix | 🔒 |
| optimization | ⚡️ |
| configuration | 👷♂️ |
| events | 🔊 |
| bug fix | 🐞 |
Styling
- Comments must have periods after every sentence.
- Underscore prefix are reserved for private and internal functions and variables in contracts.
- Variables and code expressions in comments should be backquoted (e.g.
`b`). ♡ - Memory addresses and memory related constants should be in hexadecimal format (e.g.
0x20). ♡
This is to convey semantic meaning, and aid readability for binary / hexadecimal natives. - Please keep the maximum line length, including comments to 100 characters or below. This is a balance between the old-school 80 character limit and the newer 120 character limit in the Solidity style guide. This makes it easier to read code on small or split screens. ♡
- Constants must be in
ALL_CAPS. If it is a private or internal constant in a contract, prefix it with an underscore. ♡ - Fuzz tests are simply
testDescription. Let's normalize fuzz testing. ♡
File naming
Let's stick to solmate's, to maintain drop-in compatibility for the select few classes and libraries we have.
It's a mouthfeel over consistency thing.
Compiler / Transpiler safety
Make sure your PR's are compilable with --via-ir. ♡
Care must be taken when using the slot keyword in Yul,
to ensure that the code is compatible with upgradeable contract transpilers. ♡
Others
Our SafeTransferLib library accepts address instead of ERC20. ♡
This is intentional for better cross-compatibility with OpenZeppelin.