7. Hardhat | Fund Me
Linting
solhint
is a linter for solidity which will analyze code for potential errors, checks for best practices of code and does formatting
Hardhat Deploy
hardhat-deploy
is an npm package which automates the process of writing deploy scripts for our contractsNeeds to be overriden as per github instructions
Add a
require
statement inhardhat.config.js
Make a
deploy
folder in the project which will contain deployment configuration
deploy/01-deploy-fund-me.js
Mocking & helper-hardhat-config
Mocking which is used in unit testing is creating objects that simulate behaviour of real objects
We want to use mock when using localhost or hardhat network for the price converter contract
helper-hardhat-config is a javascript file taken from
aave
repository which deploys their code to multiple different chains and multiple different addresses, it will help us get priceFeed address (of chainlink) for the chain that we usesWhen we run a local hardhat node, it will automatically deploy all the contracts
contracts/FundMe.sol
Added priceFeedAddress
in constructor for dynamic chain eth/usd mapping
contracts/PriceConverter.sol
Adjusted this contract as per FundMe contract to accept dynamic priceFeed
contract address
contracts/test/MockV3Aggregator.sol
helper-hardhat-config.js
deploy/00-deploy-mocks.js
01-deploy-fund-me.js
Utils Folder
We put commonly used scripts in this folder like the verify contract so that every one uses it (OOP)
utils/verify.js
deploy/01-deploy-fund-me.js
Solidity Style Guide
We are going to follow solidity docs official style guide to make our code much neater and readable by following orders and conventions
We use
Natspec
format to document our codeUsed later on to automatically generate code documentation for other developeres
Test FundMe
We make seperate tests for
staging
&unit
In unit tests, individual components are tested
They are done
locally
on local hardhat network
fored hardhat network
Similar to SimpleStorage tests written in previous notes section
In staging or integration tests, whole flow is tested, usually done before deploying to production
They are done on a
testnet
Debugging & Breakpoints
We can pin a breakpoint in vscode & use
javascript debug terminal
to debug the code and see variable values on the breakpoints
Solidity-Console-Log
In solidity, we can import
hardhat/console.sol;
and useconsole.log()
inside the solidity code to debug the contract
Storage in Solidity
Each global/storage variable is stored seperately in the storage
Each slot is 32 bytes long and represents the bytes version of the object
e.g, uint256 25 is 0x000...0019 since thats the hex representation
For aa "true" boolean, it would be 0x000...001 since thats its hex
For dynamic values like mappings and dynamic arrays, the elements are stored using a hashing function. More info in documentation
For arrays, a sequential storage spot is taken up for the length of the array
For mappings, a sequantial storage spot is taken up, but left blank
Constants and immutable variables are not stored in storage, but they are considered part of the core of the bytecode of the contract
getStorageAt
We can query smart contracts to find out values of stored variables at a particular slot
Gas & OpCodes
When we compile our contracts, in our bytecode object, there are opcodes present. Each opCode represent an operation in the contract
Each opCode has a gas price associated with it
SLOAD
opcode is used to load word from storage and it costs 800 gasSSTORE
opcode is used to save word to storage and it costs 20000** gasTherefore, in our contracts, we prepend
s_
keyword with variable names to denote that they are storage varaibles and will cost a lot of gas
Solidity Chainlink Style Guide
For normal contract users, we should make the
s_<variables>
private and make naming friendly getter functions for them.
Reference Code
https://github.com/Noman-Aziz/Hardhat-101-FundMe
Last updated