makemake's blog

Rainshower solidity code guidelines

• 2 min read

Rainshower is a protocol that relies on being modular. Users can program and build their strategies, financial instruments, and more. Due to this, we must have a very high standard of code quality and readability. I am releasing the Rainshower solidity guidelines to gather feedback and suggestions. I hope that projects adopting the following guidelines will make DeFi more secure and auditable.

Rainshower code guidelines

The following are some basic guidelines all contract code in this repository must follow. It is mostly copied from the JPL guide for defensive C/C++ programming, with added modifications for the EVM/Solidity.

Language Compliance

  • Do not stray outside the language definition.
  • Practice using static source code analyzers.
  • Do not ignore warnings.

Predictable Execution

  • Use verifiable loop bounds for all loops.
  • Do not use direct or indirect recursion.

Defensive Coding

  • Declare variables at smallest possible level of scope.
  • Check the return value of functions if relevant.
  • Check the validity of values passed to functions if relevant.
  • Use static and dynamic assertions as sanity checks.
  • Make the order of evaluation in compound expressions explicit.
  • Avoid using expressions with side effects.
  • Avoid downcasting/narrow conversion; precision must not be lost.
  • Avoid implicit type conversions.

Code Clarity & Optimization

  • Avoid using Yul. Prioratise readability over gas.
  • Do not place code above pragma and import directives.
  • Place no more than one statement or declaration per line of text.
  • Use short functions with a limited number of parameters.
  • Avoid the use of modifiers.
  • Do not use operator overloading.
  • Do not use function overloading.
  • Give variables and functions meaningful names.
  • Try to pack structures into single storage slots, reducing width of fields where possible or giving up precision when unnecessary.
  • Avoid string, bytes, or other variable size types except when absolutely necessary.
  • Don’t write to storage when data can be emitted as logs and queried out of band later if needed.

Credits

This document is inspired by the JPL C coding guidelines. A big thank you to everyone else who reviewed and gave feedback! It’s very much appreciated.

Vukašin Gostović

Im makemake and I like it when people put blocks in a chain and turn that into a database. Love building useful programs and anything infra. I like reading about psychology, sociology, and philosophy. I have been making computers do stuff since i was ~11 years old. Rust is pretty cool. I'll mostly be writing about Ethereum and blockchains as that's what my time is mostly preocupied by. Feel free to reach out via my links below if you have any inquiries!