A Few Considerations For Designing Smart Contracts
For traditional coding, it is a prevalent practice to segregate the code into various sections, which is also true in designing smart contracts. There are a number of libraries available which contain modules that can be used when writing a contract. It is also preferable to reuse such already available modules since this widely reduces the risk of committing an error and saves valuable time to focus on the ‘unique’ features of the contracts at hand. Even when a module needs to be modified to fit some particular needs, reuse of the corresponding tests to ensure nothing gets broken is highly recommended.
Hence, it is always advisable not to overdo the contractor to use fanciful coding techniques. Instead, keep it modest, especially because most contracts used by the public are going to have the corresponding source attached on the blockchain for anybody to inspect and validate. Having a clear, simple contract that is easy to understand gains more trust and is actually less likely to contain flaws than a large over-engineered contract doing way more than actually needed.
When designing smart contracts, it is important to think about security from the very start. Since contracts are public and visible on the blockchain, everybody can potentially call every function. Even if you do not submit the source code, there is still the bytecode so everyone with the right understanding of the EVM and proper endurance can figure out what the contract does and call it. Hence, it’s not a very good idea to count on security by obscurity. In order to avoid this, most contracts implement the owner pattern that can be used to restrict the highest state “administrator” change functions, like setup, start, stop, and kill.