How to Create a Smart Contract on Ethereum: 12 Solidity Best Practices

Top 12 Solidity Best Practices for Ethereum Smart Contracts

1. Implement Invariants

   Solidity triggers an asset safeguard in case an assertation fails. Developers can use the assert() function to fix the token to Ether issuance ratio in a token issuance contract.

2. Remember About the Integer Divisions

   Remember that in Ethereum smart contracts developed using Solidity, integer divisions round down to the nearest integer. Therefore, store both the denominator and the numerator or use a multiplier for more precision.

3. Keep Fallback Functions Simple

   Fallback functions act as a default response when there’s surplus gas or there are no matching functions. Given the nature of fallback functions, it’s crucial to keep them simple, concise, and directly address the purpose they serve. Otherwise, you may face unforeseen issues or confusion among those interacting with the smart contract.

4. Use Modifiers Properly

   The code in the modifier is generally executed before the function body, which can break the checks-effects-interactions pattern if state changes or external calls occur. Hence, Ethereum smart contract developers must use modifiers for replacing the duplicate condition checks across various functions. Smart contract developers can also use require() or revert() inside the function to improve the code readability and facilitate auditing.

5. Use Convenience Functions Properly

   Convenience functions include assert() and require(), which are used to search for conditions and throw an exception if the conditions aren’t met. The assert() function is used in testing for internal errors and verifying variants. The require() function validates the return values of calls and ensures that conditions are valid.

6. Check Data Length in Fallback Functions

   Developers should check the data length of fallback functions, as they are used not only for Ether transfers but also when there are no matching functions. Therefore, if you intend to use the fallback function only to log the received Ether, you must ensure that the data is empty. Otherwise, callers will notice that your contract is not being used correctly.

7. Be Attentive to Abstract Contract and Interfaces

   Both abstract contracts and interfaces offer a flexible and reusable approach for contract design before implementation. However, interfaces have restrictions on storage access or inheritance from other interfaces and don’t support the function’s implementation. This makes abstract contracts a more practical choice. Thus, if a contract inherits from an abstract contract, it must implement all unrealized functions; otherwise, it will also become abstract.

8. Safeguard the Pragmas

   Pragma indicates the version of the compiler that was intended by the authors of the contract. It’s essential to deploy the contracts with the relevant compiler version and flags with which they have been tested the most. Safeguarding the Pragma ensures that you don’t deploy the contracts using a different compiler with a higher risk of undetected bugs.

9. Use Events For Monitoring Contract Activity

   Events can be used to document everything that happens in a smart contract. Additionally, events can be used for triggering functions in the user interface and tracking the transactions history. All transactions that pass through a contract will appear in the events list of that contract, along with the amount of money. Emitted events remain in the blockchain along with other contract data and are always available for future audits.

10. Know That “Built-ins” Can be Shadowed

    Shadowing “built-ins” can be used to override the contract’s functionalities, which can be misleading to the contract users. Therefore, auditors and contract users need to know the entire source code of the contract in the application they intend to use.

11. Avoid Using tx.origin

    Avoid using tx.origin for authorization, as it limits interoperability. Another contract that has funds in your contract can call it using some method. This will lead to your contract authorizing the transaction because your address is currently tx.origin. It’s better to use msg.sender for authorization instead.

12. Use Explicit Marking

    A payable modifier must be used for all functions receiving Ether, and it’s only applicable to calls from external contracts. Developers should also explicitly mark visibility in functions and state variables to facilitate easy detection of incorrect assumptions regarding the variable’s accessibility.