Skip to main content

Como configurar diretrizes de codificação para a revisão de código do GitHub Copilot

Saiba como personalizar a Revisão de código do Copilot com diretrizes de codificação personalizadas.

Note

As diretrizes de codificação personalizadas são limitadas a participantes selecionados na versão prévia pública da Revisão de código do Copilot e só estão disponíveis como parte de uma assinatura do GitHub Copilot Enterprise.

Sobre as diretrizes de codificação

Você pode personalizar a Revisão de código do Copilot com diretrizes de codificação personalizadas escritas em linguagem natural. Para obter mais informações sobre a Revisão de código do Copilot, confira “Como usar a revisão de código do GitHub Copilot”.

Com as diretrizes de codificação, o Copilot pode fornecer comentários com base no estilo de codificação e nas melhores práticas específicas da sua organização.

Como a Revisão de código do Copilot é alimentada por um grande modelo de linguagem, ela pode ajudar na imposição de diretrizes de codificação que não são cobertas pela sua ferramenta de análise estática ou pelo linter.

As diretrizes de codificação são configuradas no repositório. Você pode criar e habilitar até seis diretrizes de codificação por repositório.

Note

  • As diretrizes de codificação só funcionam com as linguagens com suporte na revisão de código do Copilot. Para ver uma lista de linguagens com suporte, confira “Como usar a revisão de código do GitHub Copilot”.
  • As diretrizes de codificação só se aplicam às revisões de código realizadas pelo Copilot. As diretrizes não afetam as sugestões de preenchimento de código do Copilot nem o código sugerido nas respostas do Chat do Copilot.

Recomendações para as diretrizes de codificação

  • Use uma linguagem simples, clara e concisa para descrever a diretriz de codificação.
  • Seja o mais específico possível sobre o que Copilot deve procurar – ou seja, o que você *quer ou não ver no código.
  • Confira os “Exemplos de diretrizes de codificação” *abaixo para ter inspiração.
  • Não tente usar diretrizes de codificação para impor diretrizes de estilo que podem ser abordadas *na ferramenta de análise estática ou no linter.
  • Não use palavras ambíguas ou que possam ser interpretadas de maneiras diferentes.
  • Não tente colocar várias ideias diferentes em uma só diretriz de codificação.*

Como criar uma diretriz de codificação

  1. Em GitHub, acesse a página principal do repositório.

  2. Abaixo do nome do repositório, clique em Configurações. Caso não consiga ver a guia "Configurações", selecione o menu suspenso , clique em Configurações.

    Captura de tela de um cabeçalho de repositório que mostra as guias. A guia "Configurações" é realçada por um contorno laranja-escuro.

  3. Na seção “Código e automação” da barra lateral, selecione Copilot e depois Revisão de código.

  4. Selecione Criar diretriz.

  5. Em “Nome”, dê um nome à diretriz de codificação.

  6. Em “Descrição”, forneça uma descrição da diretriz de codificação de até 600 caracteres. Isso será usado pelo Copilot para entender seu estilo de codificação e decidir quando deixar um comentário.

    A forma como você escreve a descrição tem um grande impacto na qualidade dos comentários que serão gerados pelo Copilot. Para obter ajuda com a escrita de diretrizes de codificação eficazes, confira “Recomendações para as diretrizes de codificação” acima e “Exemplos de diretrizes de codificação” abaixo.

  7. Opcionalmente, limite a diretriz de codificação a tipos de arquivo ou caminhos específicos selecionando Adicionar caminho de arquivo e adicionando padrões de caminho.

    Você pode usar a sintaxe fnmatch para definir os caminhos de destino, com * como um curinga para corresponder a qualquer cadeia de caracteres.

    Como o GitHub usa o sinalizador File::FNM_PATHNAME para a sintaxe File.fnmatch, o curinga * não corresponde aos separadores de diretório (/). Por exemplo, qa/* corresponderá a todos os branches que começam com qa/ e que contêm uma barra "/", mas não corresponderá a qa/foo/bar. Você pode incluir qualquer quantidade de barras "/" após qa com qa/**/*, o que corresponderá, por exemplo, a qa/foo/bar/foobar/hello-world. Você também pode estender a cadeia de caracteres qa com qa**/**/* para tornar a regra mais inclusiva.

    Para obter mais informações sobre as opções de sintaxe, confira a documentação de fnmatch.

  8. Teste a diretriz de codificação para verificar se ela funciona conforme o esperado.

    1. Selecione Adicionar amostra.
    2. Adicione uma amostra própria ou pressione Generate code sample para gerar automaticamente um código de exemplo com base no título e na descrição.
    3. Selecione Salvar para salvar o código de exemplo.
    4. Teste a diretriz de codificação em relação à amostra pressionando Executar.
  9. Salve a diretriz de codificação e ative-a selecionando Salvar diretriz.

Como executar uma revisão com diretrizes de codificação

Quando você solicita uma revisão do Copilot, ele usará automaticamente as diretrizes de codificação habilitadas do repositório para revisar seu código. Para obter mais informações, confira "Como usar a revisão de código do GitHub Copilot".

Os comentários gerados com base em uma diretriz de codificação incluirão uma mensagem, realçando a origem dela.

Captura de tela de um comentário produzido com base em uma diretriz de codificação personalizada.

Exemplos de diretrizes de codificação

Exemplo 1: evite usar números mágicos

Título: Avoid using magic numbers

Descrição: Don't use magic numbers in code. Numbers should be defined as constants or variables with meaningful names.

Padrões de caminho: **/*.py

Exemplo 2: não use SELECT * em consultas SQL

Título: Don't use `SELECT *` in SQL queries

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

Padrões de caminho: nenhum (aplica-se a todos os tipos de arquivo, pois as consultas SQL podem ser inseridas no código).

Exemplo 3: use fetch para solicitações HTTP

Título: Use `fetch` for HTTP requests

Descrição: Use `fetch` for HTTP requests, not `axios` or `superagent` or other libraries.

Padrões de caminho: **/*.ts, **/*.js, **/*.jsx, **/*.tsx

Exemplo 4: sempre adicione tags às métricas com o ambiente atual

Título: Always tag metrics with the current environment

Descrição: Always include a `env` tag with the current environment when emitting metrics, for example, `env:prod` or `env:dev`.

Padrões de caminho: */*.go, */*.java