Configuring coding guidelines for GitHub Copilot code review

About coding guidelines

You can customize Copilot 코드 검토 with custom coding guidelines written in natural language. For more information on Copilot 코드 검토, 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 코드 검토 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.

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 do or don't want to see in your code.
• Do take a look at the Coding guidelines examples below for some inspiration.
• Don't try to use coding guidelines to enforce style guidelines that can be covered by 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

1. GitHub에서 리포지토리의 기본 페이지로 이동합니다.

2. 리포지토리 이름 아래에서 설정을 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

   

3. In the "Code & automation" section of the sidebar, click Copilot, then Code review.

4. Click Create guideline.

5. Under "Name," give the coding guideline a name.

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

7. 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/로 시작하고 단일 슬래시를 포함하는 모든 분기와 일치하지만 qa/foo/bar과 일치하지 않습니다.. 다음과 같이 qa과 일치하는 qa/**/*는 슬래시를 원하는 대로, 예를 들어 qa/foo/bar/foobar/hello-world 포함할 수 있습니다. qa 문자열을 qa**/**/*와 확장하여 규칙을 더 포괄적으로 만들 수도 있습니다.

   구문 옵션에 대한 자세한 내용은 fnmatch 문서를 참조하세요.

8. Test your coding guideline to make sure it works as expected.

   1. Click Add sample.
   2. Add your own sample, or press Generate code sample to automatically generate a code sample based on your title and description.
   3. Click Save to save the code sample.
   4. Test the coding guideline against your sample by pressing Run.

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