day26. hardhat – linter –

“lint”や”linter”は、プログラムのソースコードを解析し、様々な問題や非推奨の使用方法、構文エラー、スタイルの乖離、潜在的なバグなどを検出するツールのことを指します。これらのツールは、コードの品質や整合性を向上させるのに役立ちます。

linterとは

lintの名前の由来は、古い時代のコンピュータが糸くず（英: lint）のような小さなフィラメントを使って動作していたことからきており、この糸くずが問題を引き起こすことがあったため、それにちなんで名付けられました。このような糸くずのような小さな問題をコードから取り除くことがlinterの目的となっています。

多くのプログラミング言語やフレームワークには、その言語やフレームワーク専用のlinterが存在します。Solidityの場合には、次のようなlinterがあります。

1. Solhint: Solhintは、Solidityのコードスタイルとセキュリティの問題を検出する人気のあるlinterです。スタイルガイドの違反や潜在的なセキュリティリスクを指摘してくれます。
2. MythX: MythXは、Solidityのスマートコントラクトのセキュリティ分析ツールです。潜在的な脆弱性やバグを自動的に検出します。MythXは厳密にはlinterではありませんが、コードの品質とセキュリティを向上させるためのツールとして、linterと同様の目的で使用されることが多いです。
3. Slither: Slitherは、Trail of Bitsによって開発されたSolidityの静的分析ツールです。多数の脆弱性やバグを検出する能力があります。
4. Surya: Suryaは、Solidityのコードベースを視覚化や解析するためのツールキットです。関数の呼び出しの流れを理解したり、特定の関数や変数の依存関係を視覚化するのに役立ちます。

linterは以下のような利点を提供します：

1. コードの品質の向上: linterはコード内の潜在的な問題やバグを早期に検出し、開発者がそれらの問題を修正するのを助けます。
2. 統一されたコードスタイル: すべての開発者が同じスタイルガイドに従ってコーディングすることで、コードの読みやすさや保守性が向上します。
3. コードレビューの効率向上: linterによって基本的なスタイルや構文の問題が検出・修正されるため、実際のコードレビューの際にはロジックやアーキテクチャに関する問題に焦点を当てることができます。

多くの開発チームやプロジェクトでは、コードをコミットする前やプルリクエストを作成する前にlinterを実行することが推奨されています。これにより、コードの品質を一定以上に保つことができます。

※　Solhintの設定については、Day20で解説しています。

linterの実行

Funding.solに対してのlinterの実行結果は次のようになりました。

% 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.

ここでは4つのwarning（警告）が出ています。Solhintが出す問題点の重要性（Severity）としては、次の3つのラベルがあります。

1. error: これは最も重要なレベルで、コードに潜在的な問題や脆弱性があることを示します。エラーは、スマートコントラクトのセキュリティや機能に影響を与える可能性があります。エラーが報告された場合、その問題を直ちに修正することが推奨されます。
2. warning: 警告はエラーよりも重大性が低いものの、スマートコントラクトの最適化やクリーンなコードの維持のために注意すべき点を指摘します。警告に対処することで、コードの品質やメンテナンス性を向上させることができます。
3. info: 情報レベルは、一般的なヒントや改善の提案を提供します。これらは必ずしも問題ではありませんが、考慮する価値のある事項を示唆しています。

実際のwarningの該当箇所を確認したところ次のようになります。

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
    }
...

• 14〜16行目: 変数名の命名規則には、主としてmixedCase（camelCase）とsnake_caseの2つがあります。ここでの警告はmixedCaseになっていないというものですが、s_やi_と付けているのは、変数の種類がstorageかimmutableかを明示的に区別するために付けているものなので、対応の必要はありません
  • mixedCase … 小文字で始まり、それ以降の単語の先頭は大文字で始まる書き方
  • snake_case … すべて小文字で、単語の区切りとしてアンダースコア（_）を使う書き方
• 49行目: require文は2つの引数を取りえて、1つ目はboolean変数（真偽値）、2つ目は1つ目がfalseの場合のエラーメッセージです。ここでの警告は、require文に2つ目の引数として指定されるべきエラーメッセージがないというものです。ただし、2つ目の引数はオプショナルで省略できるため無視しても問題はありません。

ご意見をお聞かせください！

この記事、または、web3チュートリアル全体について、是非、あなたのご意見をお聞かせください。
アンケートはこちらからご回答いただけます。

無料相談承ります

オンラインでの無料相談を承っています。ご希望の方は、お問い合わせフォームよりご連絡ください。
ITの専門家があなたのご質問にお答えいたします。