How to Set up a Framework: A Developer’s Guide

Written by mishunin | Published 2022/08/04
Tech Story Tags: software-development | software-engineering | software-testing | agile-software-development | software-engineer | software-developer | enterprise-software | framework

TLDRIn HashEx, use Hardhat, we have created a pre-configured project with the most useful development projects connected to it and set up according to developers’ needs. By using boilerplate, you can get ready-for-use software out of the box, immediately starting the development of the project. The repository contains many useful plugins, such as Solhint, Echidna, Docgen, Slither, Prettier and Docgen. For developing Solidity smart contracts, we use the project's initial repository.via the TL;DR App

New developers often don’t know how to set up a framework for smart contract development to make the process as efficient and secure as possible.
For developing Solidity smart contracts, we In HashEx, use Hardhat, and for our internal needs, we have created a pre-configured project with the most useful development projects connected to it and set up according to the developers’ needs. 

The Useful Effects of Boilerplate

By using boilerplate you can get ready-for-use software out of the box, immediately starting the development of the project.
A prepared README can help with the usage of preset plug-ins:
  • Coverage shows how well the contracts are covered during testing.
  • Prettier formats the code to provide a better code style.
  • Docgen automatically generates contract documentation.
  • Solhint is a Solidity code linter
  • Slither is an automated analyzer for Solidity code with the purpose of vulnerability detection.
  • Echidna is required for fuzzing/property-based contract testing. 
README also includes instructions on contract testing and deployment. It also describes testing if there’s a need to create a fork of a public network.

How to Use the Initial Repository

To start using the initial repository, you have to clone this repository and install the packages it requires. This can be done using the following commands: 
  • If you’re installing it through npm
npm install
  • If you’re installing it through yarn
yarn
After that, you have to familiarize yourself with the README.md, create a config.js file following the example of the config.example.js file, then insert API keys as well as private keys (this file is located in .gitignore so it won’t be uploaded to GitHub). 
After that, you can attempt compilation of the project and launch the tests.
You can also try to run different plugins and make sure that they function properly. 
When all this is finished, you can start developing the project. 
The repository contains many useful plugins. 

Coverage

This plugin assists with writing tests and contract testing. It allows finding the spots within the contract that are not covered by tests and because of that, can potentially contain an error or a vulnerability. 

Prettier

This plugin helps with keeping the repository in a presentable condition, including its visual aspect. The main goal is to achieve a quality code style. 
It’s recommended to run this plugin every time before the commit or deployment.

Docgen

This plugin assists with writing the documentation for the contract. The documentation written in a specific way (NatSpec) within the contract files, will be converted into a presentable .md file so that anyone attempting to figure out exactly how the contract works, could do it using said documentation. 

Solhint

This plugin serves for checking the code’s Security, Style Guide, and Best Practices. It suggests changes that have to be made for the code to follow the commonly used rules of contract writing. 

Slither

This plugin specializes in finding potential vulnerabilities within the code, using static analysis. Vulnerabilities such as reentrancy, non-secure external calls, etc. can be discovered with this plugin. 

Echidna

This plugin is used for fuzzing/property-based contract testing. It requires writing specific contracts that will be tested. Examples can be found in the repository in the  /contracts/echidna-test folder. 
The point of this type of testing is to attempt to break the in-contract invariants, that are supposed to always be run. This is how the contract is checked.
It attempts to apply random actions by calling functions in random order with random arguments.
This type of testing isn’t a universal cure, it only assists with testing. There have been cases of a contract passing Echidna testing without a vulnerability being discovered. This happens because not every possible combination is tried, but a specific subcollection.

Written by mishunin | CEO HashEx
Published by HackerNoon on 2022/08/04