Skip to main content

Настройка рекомендаций по написанию кода для проверки кода GitHub Copilot

Узнайте, как настроить Проверка кода Copilot с помощью пользовательских рекомендаций по программированию.

Note

Пользовательские рекомендации по программированию ограничены выбранными участниками в public preview Проверка кода Copilot, и доступны только в рамках подписки на GitHub Copilot Enterprise.

Рекомендации по написанию кода

Вы можете настроить Проверка кода Copilot с помощью пользовательских рекомендаций по программированию, написанных на естественном языке. Дополнительные сведения о Проверка кода Copilotсм. в разделе "Использование проверки кода GitHub Copilot".

С помощью рекомендаций по написанию кода Copilot могут предоставлять отзывы на основе конкретного стиля написания кода и рекомендаций вашей организации.

Так как Проверка кода Copilot используется большой языковой моделью, она может помочь в применении рекомендаций по программированию, которые не охватываются средством анализа linter или статического анализа.

Рекомендации по написанию кода настраиваются на уровне репозитория. Для каждого репозитория можно создавать и включать до 6 рекомендаций по написанию кода.

Note

  • Рекомендации по написанию кода работают только с языками, поддерживаемыми обзором кода Copilot. Список поддерживаемых языков см. в разделе "Использование проверки кода GitHub Copilot".
  • Рекомендации по написанию кода применяются только к проверкам кода, выполняемым Copilot. Рекомендации не влияют на предложения по завершению кода Copilot или код, предлагаемый в ответах Copilot Chat.

Dos и не подходит для рекомендаций по написанию кода

  • Используйте простой, понятный и краткий язык для описания руководства по программированию.
  • Будьте как можно более конкретными о том, что Copilot должен искать - то есть то, что вы делаете или не хотите видеть в коде.
  • Ознакомьтесь с приведенными ниже примерами рекомендаций по написанию кода.
  • **** Не пытайтесь использовать рекомендации по программированию для применения рекомендаций по стилю, которые могут быть рассмотрены средством анализа linter или статического анализа.
  • **** Не используйте формулировку, которая неоднозначна или может быть интерпретирована разными способами.
  • Не пытайтесь соответствовать нескольким различным идеям в одном руководстве по программированию.

Создание руководства по написанию кода

  1. На GitHubперейдите на главную страницу репозитория.

  2. Под именем репозитория щелкните Settings. Если вкладка "Параметры" не отображается, выберите раскрывающееся меню и нажмите кнопку "Параметры".

    Снимок экрана: заголовок репозитория с вкладками. Вкладка "Параметры" выделена темно-оранжевым контуром.

  3. В разделе "Код и автоматизация" боковой панели щелкните Copilot, а затем проверьте код.

  4. Нажмите кнопку " Создать руководство".

  5. В разделе "Имя" укажите руководство по написанию кода.

  6. В разделе "Описание" укажите описание руководства по программированию до 600 символов длиной. Это будет использоваться Copilot для понимания стиля написания кода и принятия решения о том, когда следует оставить комментарий.

    Как вы пишете описание, имеет большое влияние на качество комментариев, которые Copilot будут создаваться. Дополнительные сведения о написании эффективных рекомендаций[ по программированию см. в разделе "Рекомендации по написанию кода и рекомендации по программированию" ниже](#coding-guidelines-examples).

  7. При необходимости ограничьте руководство по написанию кода определенным типам файлов или путям, нажав кнопку "Добавить путь к файлу" и добавив шаблоны путей.

    Синтаксис можно использовать fnmatch для определения путей к целевому объекту с * подстановочным знаком для сопоставления любой строки символов.

    Так как GitHub использует File::FNM_PATHNAME флаг для синтаксиса File.fnmatch , * подстановочный знак не соответствует разделителям каталогов (/). Например, будет соответствовать всем ветвям, qa/* начинающимся с qa/ и содержащим одну косую черту, но не совпадать qa/foo/bar. Вы можете включить любое количество косых черт после qa qa/**/*, которое будет соответствовать, например qa/foo/bar/foobar/hello-world. Можно также расширить qa строку, qa**/**/* чтобы сделать правило более инклюзивным.

    Дополнительные сведения о параметрах синтаксиса см. в документации по fnmatch.

  8. Проверьте руководство по программированию, чтобы убедиться, что он работает должным образом.

    1. Нажмите кнопку "Добавить пример".
    2. Добавьте собственный пример или нажмите клавиши Создайте пример кода для автоматического создания примера кода на основе заголовка и описания.
    3. Нажмите кнопку "Сохранить", чтобы сохранить пример кода.
    4. Проверьте руководство по написанию кода для примера, нажав клавиши Run.
  9. Сохраните руководство по написанию кода и включите его, нажав кнопку "Сохранить руководство".

Выполнение проверки с рекомендациями по написанию кода

При запросе проверки из Copilotон автоматически будет использовать рекомендации по написанию кода с поддержкой репозитория для просмотра кода. Дополнительные сведения см. в разделе «Использование проверки кода GitHub Copilot».

Примечания, созданные на основе руководства по написанию кода, будут содержать сообщение, подчеркивающее их источник.

Снимок экрана: комментарий, созданный в пользовательском руководстве по написанию кода.

Примеры рекомендаций по написанию кода

Пример 1. Избегайте использования магических чисел

Титул: Avoid using magic numbers

Description (Описание): Don't use magic numbers in code. Numbers should be defined as constants or variables with meaningful names.

Шаблоны пути: **/*.py

Пример 2. Не используйте SELECT * в запросах SQL

Титул: 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.

Шаблоны пути: нет (применяется ко всем типам файлов, так как запросы SQL могут быть внедрены в код).

Пример 3. Использование fetch для HTTP-запросов

Титул: Use `fetch` for HTTP requests

Description (Описание): Use `fetch` for HTTP requests, not `axios` or `superagent` or other libraries.

Шаблоны пути: **/*.ts, **/*.js, **/*.jsx``**/*.tsx

Пример 4. Метрики тегов с текущей средой

Титул: 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`.

Шаблоны пути: */*.go, */*.java