Minimum security:
~ All code should be stored in a version control system, such as git
~ All code changes should be made via pull requests
~ All pull requests should have at least one reviewer. If this is a personal project, please consider finding another personal author and a transactional code reviewer.
~ Compile, deploy and run a suite of tests against your code with a single command using the development Ethereum environment (see: Truffle)
~ Having run the code through basic code analysis tools like Mythril and Sliter, it's best to compare the differences in the output before merging each pull request.
~Solidity code editor doesn't issue any warnings
~Your code is well documented
These items above are a good start for writing a smart contract, but there is much more to be aware of while writing the code. For more items and their detailed explanations, please refer to the process quality checklist provided by DeFiSafety . Part of DeFiSafete’s safety rating grade for a project includes whether the project complies with a quality checklist. Follow these review processes:
~ Generate safer code through reproducible automated testing
~ Reviewers will be able to review your items more efficiently
~ friendly to new developers
~ Allows developers to quickly iterate, test and get feedback on changes
~ Less likely to rollback code
The development of smart contracts is still difficult, especially for novices, there are some bugs that cannot be found by themselves, and it is more troublesome to build the environment. Recently, a blockchain community was discovered. The chainpip community has integrated the contract development environment . It can directly perform one-key test, which is very friendly to novices~