Let's continue our discussion on best practices. Use appropriate data types, understand that Ethereum Virtual Machine, is a two 56-bit processor optimized for integer computations. It has a stack machine for execution with limited set of appcodes. Consider the ballot example discussed in the last module. For example, a variable proposal name of string type can be expensive, since a string in a smart contract is a dynamic sized variable. So, how can we address this issue? Instead of using a variable string name for the proposals, use an integer identification for the proposal. This ID is used as an index into the array of proposals. This is the number returned by the function winning proposal. A user-level application outside the chain can then map the ID to proposal name if so desired. Make sure you use the integer arithmetic for most of your computational needs. 256-bit processor for the EVM, is indeed very large in comparison to your regular 64-bit processor, four times the sheer number of bits. With every doubling of the number of bits of the container size the range of values increases exponentially. Solidity also provides different sizes ranging from eight bits Uint8 all the way to 256 bits Uint256. Understand the public visibility modifier for data. All state variables are created as private. Any variable on the block chain is viewable to all, irrespective of the visibility modifier. You have to explicitly state that a variable is public. When a variable is declared public, Solidity compiler automatically creates a getter method to view the value of the variable. Internal to the contract, the variable is accessed as data, externally it is accessed as a function. Be aware of this difference in accessing the public data and the getter method. Maintain a standard order for different function types within a smart contract, according to their visibility as specified in Solidity docs. The recommended order for functions within a smart contract are; constructor, fallback function, external, public, internal, private. Within a grouping, plays the constant functions last. Functions can have many different modifiers, functions have visibility modifiers as well as predefined and custom access modifiers. The visibility modifiers for the function should come before any custom access modifiers. Multiple modifiers that apply to a function, by specifying them in a white space separated list and are evaluated in the order presented. Hence, if the output of one modifier depends on the other, make sure you order them in the right sequence. For example, function buy, has three modifiers specified in the following order; payable, enoughMoney, item available. Use Solidity-defined payable modifier when sending value. Only through payable functions, can an account send value to another address. Payable is a reserved keyword, you may use payable as an addition to an existing function. In the following example, the bid function is to bid for an auction item, the transaction bid invoking bid can send either B only if the function is payable. In other words, deposit, register, and bid functions are allowed to send money to the target smart contract address. Pay attention to the order of statements within a function. The first withdraw function checks the condition first and then allows for withdraw, the second one has a withdraw code first and then condition check. Something similar to this, resulted in parody wallet losing several million ethers, when a smart contract was killed before moving the ethers. Use modifier declarations for implementing rules. Use function access modifiers for; implementing rules, policies and regulations. Implementing common rules for all who may access a function, declaratively validating application specific conditions and providing auditable elements to allow verification of the correctness of a smart contract. Using events in smart contract. Use events to log important milestones, during the span of a smart contract execution especially long running ones. Events can carry at most three index parameters that can be used efficiently for searching through the events in the block chain. Instead of a client application, polling a smart contract using external functions, events can push information to the application that would have set up listeners to specific events. Beware of "now" time variable. Now is the alias for block timestamp of the block indicating the universal time when the block and the transaction within it are mined and recorded. Variable now can be used for approximate elapsed time comparison, as we illustrated in the ballot example. However, it is not a good practice to use it for computation within the application logic. Also, variable now provides time to the accuracy of seconds if fine granular time is required, you may have to resort to other mechanisms. Use secure hashing for protecting data. Recall that hashing is a very important function in a block chain. Data in the block chain is viewable by all. This means that we may want to secure hash, to protect its visibility. Solidity provides a variety of built-in functions for standard secure hash functions. Keccak, SHA-256, RIPEMD-160 are Solidity functions available to use for hashing application data.
