Day 26. hardhat – linter –

“lint” or “linter” refers to tools that analyze the source code of programs to detect various problems such as deprecated usage, syntax errors, style discrepancies, and potential bugs. These tools are helpful in improving the quality and consistency of the code.

What is a linter?

The term “lint” comes from the old days when computers operated using small filaments like lint (fluff), which could cause problems. The purpose of a linter is to remove such small, lint-like issues from the code.

For many programming languages and frameworks, there are linters specific to them. For Solidity, there are linters like:

1. Solhint: Solhint is a popular linter that detects issues with Solidity’s code style and security. It points out violations of style guides and potential security risks.
2. MythX: MythX is a security analysis tool for Solidity smart contracts. It automatically detects potential vulnerabilities and bugs. While not strictly a linter, MythX is often used for the same purpose of improving code quality and security.
3. Slither: Slither, developed by Trail of Bits, is a static analysis tool for Solidity. It has the capability to detect a multitude of vulnerabilities and bugs.
4. Surya: Surya is a toolkit for visualizing and analyzing Solidity codebases. It helps to understand the flow of function calls and visualize dependencies of specific functions or variables.

Linters offer benefits like:

1. Improving code quality: Linters detect potential issues and bugs early in the code, helping developers to fix them.
2. Unified code style: By having all developers follow the same style guide, the readability and maintainability of the code are enhanced.
3. Efficient code reviews: Linters detect and correct basic style and syntax issues, allowing the actual code review to focus more on logic and architecture. Many development teams and projects recommend running a linter before committing code or creating pull requests. This helps to maintain a certain level of code quality.

※ The configuration of Solhint is explained on day 20.

Running the linter

The results of running the linter on Funding.sol are as follows:

% yarn solhint contracts/Funding.sol
yarn run v1.22.19
$ /Users/username/code/token-village/funding/node_modules/.bin/solhint contracts/Funding.sol

contracts/Funding.sol
  14:5  warning  Variable name must be in mixedCase                                var-name-mixedcase
  15:5  warning  Variable name must be in mixedCase                                var-name-mixedcase
  16:5  warning  Immutable variables name are set to be in capitalized SNAKE_CASE  immutable-vars-naming
  49:9  warning  Provide an error message for require                              reason-string

✖ 4 problems (0 errors, 4 warnings)
 
✨  Done in 0.76s.

Here, there are four warnings. The severity of issues raised by Solhint can be categorized into three labels:

1. error: This is the most critical level, indicating potential problems or vulnerabilities in the code. Errors could affect the security or functionality of the smart contract and should be fixed immediately if reported.
2. warning: Warnings are less severe than errors but point out issues that should be addressed for optimizing smart contracts and maintaining clean code. Addressing warnings can improve the quality and maintainability of the code.
3. info: The information level provides general tips or suggestions for improvement. These are not necessarily problems but are worth considering.

Upon checking the actual warning locations:

contract Funding {
    // State variables
    address[] private s_funders; // #14
    mapping(address => uint256) private s_addressToAmountFunded; // #15
    address private immutable i_owner; // #16
...
    function withdraw() public onlyOwner {
...
        (bool success, ) = i_owner.call{value: address(this).balance}("");
        require(success); // #49
    }
...

• Lines 14-16: There are two primary naming conventions for variable names: mixedCase (camelCase) and snake_case. The warning here is about not using mixedCase. However, prefixes like s_ or i_ are used to explicitly distinguish whether a variable is storage or immutable, so no action is needed in this case.
  • mixedCase: Writing style where the first letter is lowercase, and subsequent words start with an uppercase letter.
  • snake_case: Writing style where all letters are lowercase, and words are separated by underscores (_).
• Line 49: A require statement can take two arguments; the first is a boolean variable (true or false value), and the second is an error message for when the first argument is false. The warning here is about the absence of the second argument, which is the error message. However, the second argument is optional and can be omitted without issue.