コードインスペクション

GoLand には、プロジェクトをコンパイルする前に、プロジェクト内の異常なコードを検出し修正するコードインスペクションのセットがあります。 IDE は、さまざまな問題を見つけてハイライトし、デッドコードを見つけ、考えられるバグやスペルの問題を見つけ、全体的なコード構造を改善することができます。

インスペクションは、すべてのプロジェクトファイルまたは特定のスコープでのみ（たとえば、本番コードまたは変更されたファイルでのみ）コードをスキャンできます。

すべてのインスペクションには、問題がコードに影響を与える可能性がある程度の重大度レベルがあります。重大度はエディター内で異なる方法でハイライトされるため、重大な問題と重要性の低いものとをすばやく区別できます。 GoLand にはあらかじめ定義された重要度レベルのセットが付属しており、独自のものも作成できます。

インスペクションとその設定は、プロファイルにグループ化されています。各プロファイルには、有効にされたインスペクション、それらが分析するファイルのスコープ、それらの重大度レベルに関する情報が含まれています。

利用可能なすべてのインスペクションとその設定にアクセスする

設定ダイアログ（Ctrl+Alt+S ）でエディター | インスペクションに移動します。
Ctrl+Alt+Shift+H を押して、表示されるポップアップでインスペクションの構成を選択することもできます。

を使用してインスペクションリストをフィルタリングします。例: 重大度または言語によってインスペクションをフィルタリングできます。

データフロー分析

データフロー分析（DFA）は、プログラミングでデータがプログラム内をどのように移動するかを理解するために使われるメソッドです。プログラムを異なる点がある地図と想像してみてください。それぞれの点はコードの一部（ステートメントや命令など）です。これらの点は、プログラムが実行される際のパスを示す線で結ばれています。 GoLand では、データフロー分析がこの地図を参照してコードを分析します。

nil 参照のデータフロー解析

nil ポインタ参照は Go 言語でよく見られるエラーです。本番環境システムでは、予期せぬパニック、クラッシュ、デッドロックを引き起こす可能性があります。典型的な原因としては、nil ポインタのフィールドへのアクセスや nil チャネルへの書き込みなどが挙げられます。

GoLand は静的コード解析を用いて nil 参照の問題を検出します。標準的な nil 参照検出機能であるインスペクションは個々の関数内（手続き内解析）で動作し、単純なケースを検出できます。

nil 値が関数、ファイル、パッケージ間を移動すると、より複雑な問題が発生します。こうした状況に対処するため、GoLand は手続き間 DFA を提供しています。この機能は、関数呼び出しを通じて値がどのように伝播するかを追跡し、コードベース全体にわたって潜在的な nil 参照の問題を検出することを可能にします。

手順内分析の詳細については、 blog.jetbrains.com のブログ投稿(英語)を参照してください。

潜在的な nil 参照を説明する

GoLand は、nil 参照の可能性のある問題をエディター内で直接ハイライト表示します。このような警告が表示された場合は、潜在的な nil 参照を説明するアクションを使用できます。

警告の上にマウスを移動するか、警告をクリックして Alt+Enter を押し、潜在的な nil 参照を説明するを選択します。
このアクションにより、問題ツールウィンドウのデータフロー分析タブが開きます。ツールは、 nil 値がコード内でどのように伝播し、どこで使用されているかを段階的に説明します。これにより、コードベース全体を検索することなく、問題を理解し、効率的に修正することができます。

クイックドキュメントでナラビリティ情報を表示する

GoLand は、クイックドキュメントポップアップに nil 可能性の情報を直接表示するようになりました。これにより、関数が nil を返す可能性があるかどうか、nil 以外のパラメーターやレシーバーを期待しているかどうかをすぐに確認できます。

コード内の関数、パラメーター、レシーバーにキャレットを置きます。
Ctrl+Q を押すとクイックドキュメントポップアップが表示されます。ポップアップ内でナラビリティ情報セクションを探してください。

リソースリーク分析

リソースリーク分析は、開かれたものの適切に閉じられていないファイルやネットワーク接続などのリソースを特定できます。 Go 言語では、このような問題はメモリリーク、パフォーマンスの低下、微細なバグ、システムリソースの枯渇につながり、重大なランタイムエラーにつながる可能性があります。

GoLand では、このインスペクションがコードをローカルで解析し、単一の関数内で潜在的なリソースリークを検出します。 io.Closer インターフェースを実装し、他の関数から返されるリソースを検出します。

分析の仕組み

インスペクションは関数内のすべての制御フローパスをチェックし、リソースが適切に閉じられていることを確認します。リソースが閉じられていないパスが少なくとも 1 つある場合、GoLand は潜在的なリソースリークについて警告を表示してハイライトします。

例：

func processLogFile(filename string) error {
	file, err := os.Open(filename) // resource leak
	if err != nil {
		return err
	}

	info, err := file.Stat()
	if err != nil {
		return err              // the file is not closed
	}

	if info.Size() == 0 {
		return fmt.Errorf("empty file") // the file is not closed
	}

	defer file.Close()
	_, _ = io.Copy(io.Discard, file)
	return nil
}
        
   

ここでの問題は、ファイルが閉じられていない早期リターンが発生することです。

警告が表示されない場合

インスペクションは誤検知を回避するように設計されています。関数がリソースの所有権を譲渡する場合、つまりリソースがプログラムの別の部分に渡され、後で閉じられる可能性がある場合、警告は表示されません。このような場合、GoLand はリソースが正しく処理されたとみなします。

リソースが次の場合には警告は表示されません:

現在の関数から返される
匿名関数で使用される
グローバル変数に代入
構造体、スライス、マップに格納される

例: 次の関数は警告をトリガーしません。

func createFile() io.Closer {
	f, _ := os.Open("/data/source.db")
	return f // ownership is transferred
}
        
   

再割り当てによる漏洩の検出

インスペクションは、再割り当てによって生じたリークも検出できます。例：

func _() {
	f, _ := os.Open("/data/source.db") // resource leak!
	if true {
		f, _ = os.Open("/data/source.db")
	}
	f.Close()
}
        
   

ここで、変数 f は Close() が呼び出される前に再割り当てされるため、最初の openFile() 呼び出しによって返されるリソースは決して閉じられません。

コードインスペクションと Qodana

Qodana プラグインをインストールする

この機能は、インストールして有効にする必要がある Qodana(英語) プラグインに依存しています。

Ctrl+Alt+S を押して設定を開き、プラグインを選択します。
マーケットプレースタブを開き、 Qodana プラグインを見つけて、インストールをクリックします (プロンプトが表示されたら、IDE を再起動します)。

IDE でコードインスペクションを実行することに加えて、 Qodana を使用してコードをインスペクションできます。

GoLand のインスペクションを、IDE を含むローカル環境や CI/CD パイプラインの一部として実行します。
CI/CD インフラストラクチャを使用して、リソースを消費するインスペクションを実行します。
CI システムの品質ゲートを使用して品質基準を強化します。
IDE と CI ツールの両方で同じインスペクションプロファイルを共有します。
セキュリティチェックやライセンス監査など、Qodana でのみ利用できるインスペクションにアクセスします。
インスペクション結果の履歴概要にアクセスします。
コミット間でインスペクション結果を比較して、進捗をよりよく理解できます。

詳細は、 Qodana を参照してください。

2026 年 5 月 22 日