Note
Custom coding guidelines are limited to selected participants in the パブリック プレビュー of Copilot code review, and only available as part of a subscription to GitHub Copilot Enterprise.
About coding guidelines
You can customize Copilot code review with custom coding guidelines written in natural language. For more information on Copilot code review, see "Using GitHub Copilot code review."
With coding guidelines, Copilot can give feedback based on your organization's specific coding style and best practices.
Because Copilot code review is powered by a large language model, it can help with enforcing coding guidelines that are not covered by your linter or static analysis tool.
Coding guidelines are configured at the repository level. You can create and enable up to 6 coding guidelines per repository.
Note
- Coding guidelines only work with languages supported by Copilot code review. For a list of supported languages, see "Using GitHub Copilot code review."
- Coding guidelines only apply to code reviews carried out by Copilot. The guidelines do not affect Copilot code completion suggestions, or code suggested in Copilot Chat responses.
Dos and don'ts for coding guidelines
- Do use simple, clear and concise language to describe your coding guideline.
- Do be as specific as possible about what Copilot should look for - that is, what you *o or don't want to see in your code.
- Do take a look at the "Coding guidelines examples" *elow for some inspiration.
- Don't try to use coding guidelines to enforce style guidelines that can be covered *y your linter or static analysis tool.
- Don't use wording that is ambiguous or could be interpreted in different ways.
- Don't try to fit multiple different ideas into a single coding guideline.*
Creating a coding guideline
-
GitHub で、リポジトリのメイン ページに移動します。
-
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。
-
In the "Code & automation" section of the side bar, click Copilot, then Code review.
-
Click Create guideline.
-
Under "Name," give the coding guideline a name.
-
Under "Description," provide a description of the coding guideline up to 600 characters long. This will be used by Copilot to understand your coding style and to decide when to leave a comment.
How you write your description has a big impact on the quality of comments that Copilot will generate. For help with writing effective coding guidelines, see "Dos and don'ts for coding guidelines" above, and "Coding guidelines examples" below.
-
Optionally, limit the coding guideline to specific file types or paths by clicking Add file path and adding path patterns.
You can use
fnmatch
syntax to define paths to target, with*
as a wildcard to match any string of characters.GitHub では
File::FNM_PATHNAME
フラグをFile.fnmatch
構文で使うため、*
のワイルドカードがディレクトリの区切り記号 (/
) と照合されません。 たとえば、qa/*
は、qa/
で始まり、1 つのスラッシュを含むすべてのブランチと照合されますが、qa/foo/bar
とは照合されません。qa
の後には、qa/**/*
を使用して任意の数のスラッシュを含めることができます。これは、たとえばqa/foo/bar/foobar/hello-world
と一致します。qa**/**/*
を使いqa
の文字列を拡張して、より包括的にすることもできます。構文のオプションについて詳しくは、fnmatch のドキュメントを参照してください。
注: 分岐保護規則では
fnmatch
構文のすべての式がサポートされているわけではありません。 次の制約に注意してください。- GitHub はブランチ保護規則でバックスラッシュの使用をサポートしていないため、バックスラッシュ (
\
) 文字を引用文字として使用することはできません。 - 角かっこ (
[]
) 内で文字セットを指定できますが、現在、^
演算子 (例:[^charset]
) でセットを補完することはできません。 - GitHub は
fnmatch
構文のFile::FNM_PATHNAME
をサポートしていますが、File::FNM_EXTGLOB
はサポートされていません。
- GitHub はブランチ保護規則でバックスラッシュの使用をサポートしていないため、バックスラッシュ (
-
Test your coding guideline to make sure it works as expected.
- Click Add sample.
- Add your own sample, or press Generate code sample to automatically generate a code sample based on your title and description.
- Click Save to save the code sample.
- Test the coding guideline against your sample by pressing Run.
-
Save your coding guideline, and turn it on, by clicking Save guideline.
Running a review with coding guidelines
When you request a review from Copilot, it will automatically use the repository's enabled coding guidelines to review your code. For more information, see "Using GitHub Copilot code review."
Comments generated based on a coding guideline will include a message, highlighting their source.
Coding guidelines examples
Example 1: Avoid using magic numbers
Title: Avoid using magic numbers
Description: Don't use magic numbers in code. Numbers should be defined as constants or variables with meaningful names.
Path patterns: **/*.py
Example 2: Don't use SELECT *
in SQL queries
Title: Don't use `SELECT *` in SQL queries
Description: Don't use `SELECT *` in SQL queries. Always specify the columns you want to select. `COUNT(*)` is allowed.
Path patterns: None (applies to all file types, as SQL queries may be embedded in code).
Example 3: Use fetch
for HTTP requests
Title: Use `fetch` for HTTP requests
Description: Use `fetch` for HTTP requests, not `axios` or `superagent` or other libraries.
Path patterns: **/*.ts
, **/*.js
, **/*.jsx
, **/*.tsx
Example 4: Always tag metrics with the current environment
Title: Always tag metrics with the current environment
Description: Always include a `env` tag with the current environment when emitting metrics, for example, `env:prod` or `env:dev`.
Path patterns: */*.go
, */*.java