Purpose of Contribution Guidelines
- Organize the app to make it easier to debug, maintain, and integrate new functionality.
- Create a common code paradigm used by all devs on the team.
- Share the rules of this paradigm to make it easier for new devs to contribute lasting code.
- Make the code more consistent and readable.
- Make the code easier to debug.
- Less code. Perform the greatest amount of work with the least amount of expression.
- Less state. Strive to eliminate excess state wherever possible.
- DRY. Don't Repeat Yourself (woops...)
- Functional is generally preferred over Object Oriented.
- No hard rules. Devs should be free to break any rule at any time. However, if they do wish to break a rule, they should outline their reasoning in a comment.
- Any major changes or new patterns should be posted in #code-review on Discord .
- Clean as you go. Devs rarely refactor code months later, despite their best intentions. So it's best to deliver clean code from the outset.
- Criticism and review should be frequent and good-spirited.
- This is an ongoing process. We need to debate and discuss these rules in order to improve them.
- TBD (meeting, Pull request).
- Our linter is currently set to adhere to the AirBNB JS Style guide .
- To save yourself some time, read through the review guidelines thoroughly.
- Learn the structure of the app.
- If you're tasked with interacting with a contract (TXs), learn the TX/polling/test cycle.
- Brush up on React by scouring the docs. Familiarize yourself with some of the more advanced aspects of hooks, contexts, and lazy-loading.
- If you're not comfortable with Async, take some time to browse some examples in the docs. Check out some tutorials.