When interacting with external contracts, name your variables, methods, and contract interfaces in a way that makes it clear that interacting with them is potentially unsafe. This applies to your own functions that call external contracts.
Software Recommnded Solutions
This page demonstrates a number of patterns which should generally be followed when writing smart contracts.
Protocol specific recommendations
This apply to the development of any contract system on Ethereum.When interacting with external contracts, name your variables, methods, and contract interfaces in a way that makes it clear that interacting with them is potentially unsafe.
Solidity specific recommendations
The following recommendations are specific to Solidity, but may also be instructive for developing smart contracts in other languages.An assert guard triggers when an assertion fails - such as an invariant property changing.
Deprecated/historical recommendations
These are recommendations which are no longer relevant due to changes in the protocol or improvements to solidity. They are recorded here for posterity and awareness.Ensure you're running at least version 0.4.
Solutions
The following is a list of known solutions which you should be able to use and defend against when writing smart contracts.
- Protocol specific recommendations
- Solidity specific recommendations
- Deprecated/historical recommendations
The code inside a modifier is usually executed before the function body, so any state changes or external calls will violate the Checks-Effects-Interactions pattern. Moreover, these statements may also remain unnoticed by the developer, as the code for modifier may be far from the function declaration.
Favor capitalization and a prefix in front of events (we suggest Log), to prevent the risk of confusion between functions and events. For functions, always start with a lowercase letter, except for the constructor.
