GitHub Copilot コードレビューのコーディングガイドラインの構成

Note

カスタムコーディングガイドラインは、Copilot コードレビューのパブリックプレビューの選ばれた参加者のみが使用でき、GitHub Copilot Enterprise に対するサブスクリプションの一部としてのみ利用できます。

コーディングガイドラインについて

自然言語で書かれたカスタムコーディングガイドラインを使って、Copilot コードレビューをカスタマイズできます。 Copilot コードレビューの詳細については、「GitHub Copilot コードレビューの使用」を参照してください。

コーディングガイドラインを使うと、Copilot は、organization の固有のコーディングスタイルとベストプラクティスに基づいてフィードバックを提供できます。

Copilot コードレビューは大規模言語モデルを搭載しているため、リンターまたは静的分析ツールではカバーされていないコーディングガイドラインを適用するのに役立ちます。

コーディングガイドラインは、リポジトリレベルで構成されます。リポジトリごとに最大 6 つのコーディングガイドラインを作成して有効にできます。

Note

コーディングガイドラインは、Copilot のコードレビューでサポートされている言語でのみ機能します。サポートされている言語の一覧については、「GitHub Copilot コードレビューの使用」を参照してください。
コーディングガイドラインは、Copilot によって行われるコードレビューにのみ適用されます。このガイドラインは、Copilot のコード補完候補や、Copilot Chat の応答で提案されるコードには影響しません。

コーディングガイドラインについて行って良いことと悪いこと

良い平易で明確で簡潔な言語を使って、コーディングガイドラインを記述する。
良い Copilot が模索する必要のあるもの、つまり、コードに記述されてほしいものとほしくないものを、できるだけ具体的に指定する。
良い後述する「コーディングガイドラインの例」を見て参考にする。
悪いコーディングガイドラインを使って、リンターまたは静的分析ツールで対応できるスタイルガイドラインを適用しようとする。
悪いあいまいな、または何通りにも解釈できる表現を使う。
悪い複数の異なるアイデアを 1 つのコーディングガイドラインに盛り込もうとする。

コーディングガイドラインの作成

GitHub で、リポジトリのメインページに移動します。
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウンメニューを選び、 [設定] をクリックします。
サイドバーの [Code & automation] セクションで、 Copilot をクリックしてから、[Code review] をクリックします。
[Create guideline] をクリックします。
[Name] で、コーディングガイドラインの名前を指定します。
[Description] で、コーディングガイドラインの説明を最大 600 文字で指定します。これは、Copilot がコーディングスタイルを理解し、コメントを残すべきときを判断するために使われます。

説明の書き方は、Copilot が生成するコメントの品質に大きな影響を与えます。効果的なコーディングガイドラインの書き方については、前述の「コーディングガイドラインについて行って良いことと悪いこと」と後述する「コーディングガイドラインの例」を参照してください。
必要に応じて、[Add file path] をクリックしてパスのパターンを追加し、特定のファイルの種類またはパスにコーディングガイドラインを制限します。

fnmatch 構文を使い、任意の文字列に一致するワイルドカードとして * を使って、ターゲットのパスを定義できます。

GitHub では File::FNM_PATHNAME フラグを File.fnmatch 構文で使うため、* のワイルドカードがディレクトリの区切り記号 (/) と照合されません。たとえば、qa/* は、qa/ で始まり、1 つのスラッシュを含むすべてのブランチと照合されますが、qa/foo/bar とは照合されません。 qa の後には、qa/**/* を使用して任意の数のスラッシュを含めることができます。これは、たとえば qa/foo/bar/foobar/hello-world と一致します。 qa**/**/* を使い qa の文字列を拡張して、より包括的にすることもできます。

構文のオプションについて詳しくは、fnmatch のドキュメントを参照してください。
コーディングガイドラインをテストして、期待どおりに動作することを確認します。
1. [Add sample] をクリックします。
2. 独自のサンプルを追加します。または、 [Generate code sample] をクリックして、タイトルと説明に基づいてコードサンプルを自動的に生成します。
3. [Save] をクリックして、コードサンプルを保存します。
4. [Run] をクリックし、サンプルに対してコーディングガイドラインをテストします。
[Save guideline] をクリックし、コーディングガイドラインを保存して有効にします。

コーディングガイドラインを使用したレビューの実行

Copilot にレビューを要求すると、リポジトリの有効なコーディングガイドラインを自動的に使ってコードのレビューが行われます。詳しくは、「GitHub Copilot コードレビューの使用」をご覧ください。

コーディングガイドラインに基づいて生成されたコメントには、そのソースを明確に示すメッセージが含まれます。

カスタムコーディングガイドラインから生成されたコメントのスクリーンショット。

コーディングガイドラインの例

例 1: マジックナンバーの使用を避ける

タイトル: Avoid using magic numbers

説明: Don't use magic numbers in code. Numbers should be defined as constants or variables with meaningful names.

パスパターン: **/*.py

例 2: SQL クエリで `SELECT *` を使用しない

タイトル: Don't use `SELECT *` in SQL queries

説明: Don't use `SELECT *` in SQL queries. Always specify the columns you want to select. `COUNT(*)` is allowed.

パスパターン: なし (SQL クエリはコードに埋め込まれる可能性があるため、すべてのファイルの種類に適用します)。

例 3: HTTP 要求に `fetch` を使用する

タイトル: Use `fetch` for HTTP requests

説明: Use `fetch` for HTTP requests, not `axios` or `superagent` or other libraries.

パスパターン: **/*.ts、**/*.js、**/*.jsx、**/*.tsx

例 4: 常にメトリックに現在の環境でタグを付ける

タイトル: Always tag metrics with the current environment

説明: Always include a `env` tag with the current environment when emitting metrics, for example, `env:prod` or `env:dev`.

パスパターン: */*.go、*/*.java

GitHub Copilot コード レビューのコーディング ガイドラインの構成

この記事の内容

GitHub Copilot コードレビューのコーディングガイドラインの構成