Skip to main content

Configuración de instrucciones de codificación para la revisión de código de GitHub Copilot

Aprende a personalizar la Revisión del código de Copilot con instrucciones de codificación personalizadas.

Note

Las instrucciones de codificación personalizadas se limitan a los participantes seleccionados en la versión preliminar pública de la Revisión del código de Copilot y solo están disponibles como parte de una suscripción a GitHub Copilot Enterprise.

Acerca de las instrucciones de codificación

Puedes personalizar la Revisión del código de Copilot con instrucciones de codificación personalizadas escritas en lenguaje natural. Para obtener más información sobre la Revisión del código de Copilot, consulta "Uso de la revisión de código de GitHub Copilot".

Con las instrucciones de codificación, Copilot puede proporcionar comentarios en función del estilo de codificación y los procedimientos recomendados específicos de su organización.

Dado que la Revisión del código de Copilot cuenta con tecnología de un modelo de lenguaje grande, puede ayudar a aplicar instrucciones de codificación que tu linter o herramienta de análisis estático no cubre.

Las instrucciones de codificación se configuran en el nivel de repositorio. Puedes crear y habilitar hasta 6 instrucciones de codificación por repositorio.

Note

  • Las instrucciones de codificación solo funcionan con lenguajes compatibles con la revisión de código de Copilot. Para obtener una lista de los lenguajes compatibles, consulta "Uso de la revisión de código de GitHub Copilot".
  • Las instrucciones de codificación solo se aplican a las revisiones de código realizadas por Copilot. Las instrucciones no afectan a las sugerencias de finalización de código de Copilot ni al código sugerido en las respuestas del Chat de Copilot.

Qué debes hacer o no en las instrucciones de codificación

  • Debes usar un lenguaje sencillo, claro y conciso para describir la instrucción de codificación.
  • Debes indicar de la forma más específica posible qué debe buscar Copilot, es decir, qué quieres ver o no en el código.
  • Debes echar una vistazo a los "ejemplos de instrucciones de creación de código" más adelante para que te sirvan de inspiración.
  • No intentes usar instrucciones de creación de código para aplicar instrucciones de estilo que se incluyan en tu herramienta de análisis estático o linter.
  • No debes usar términos ambiguos o que puedan interpretarse de distintas formas.
  • No intentes integrar varias ideas diferentes en una sola instrucción de creación de código.

Creación de una instrucción de codificación

  1. En GitHub, navegue hasta la página principal del repositorio.

  2. En el nombre del repositorio, haz clic en Configuración. Si no puedes ver la pestaña "Configuración", selecciona el menú desplegable y, a continuación, haz clic en Configuración.

    Captura de pantalla de un encabezado de repositorio en el que se muestran las pestañas. La pestaña "Configuración" está resaltada con un contorno naranja oscuro.

  3. En la sección "Code & automation" de la barra lateral, haz clic en Copilot y, después, en Code review.

  4. Haz clic en Create guideline.

  5. En "Name", asigna un nombre a la instrucción de codificación.

  6. En "Description", proporciona una descripción de la instrucción de codificación con un máximo de 600 caracteres. Copilot usará estos datos para comprender el estilo de codificación y decidir cuándo dejar un comentario.

    La forma de escribir tu descripción tiene un gran impacto en la calidad de los comentarios que generará Copilot. Para obtener ayuda y escribir instrucciones de codificación eficientes, consulta "Qué debes hacer o no en las instrucciones de codificación" más arriba y "Ejemplos de instrucciones de código" más adelante.

  7. Además, tienes la opción de limitar la instrucción de codificación a determinados tipos de archivo o rutas de acceso si haces clic en Add file path y agregas patrones de ruta de acceso.

    Puedes usar la sintaxis fnmatch para definir rutas de acceso a un destino, con * como carácter comodín para permitir la coincidencia con cualquier cadena de caracteres.

    Como GitHub usa la marca File::FNM_PATHNAME para la sintaxis File.fnmatch, el carácter comodín * no coincide con los separadores de directorios (/). Por ejemplo, qa/* coincidirá con todas las ramas que comienzan por qa/ y que contienen una sola barra diagonal, pero no coincidirá con qa/foo/bar. Puedes incluir cualquier número de barras diagonales después de qa con qa/**/*, que coincidiría, por ejemplo, con qa/foo/bar/foobar/hello-world. También puedes extender la cadena qa con qa**/**/* para que la regla sea más inclusiva.

    Para más información sobre las opciones de sintaxis, consulta la documentación de fnmatch.

  8. Prueba tu instrucción de codificación para asegurarte de que funciona según lo previsto.

    1. Haz clic en Add sample.
    2. Agrega tu propio ejemplo o presiona Generate code sample para generar de forma automática un ejemplo de código basado en el título y la descripción.
    3. Haz clic en Save para guardar el ejemplo de código.
    4. Prueba la instrucción de codificación en tu ejemplo; para ello, presiona Run.
  9. Guarda la instrucción de codificación y haz clic en Save guideline para activarla.

Ejecución de una revisión con instrucciones de codificación

Cuando solicites una revisión de Copilot, este usará de forma automática las instrucciones de codificación habilitadas para el repositorio a fin de revisar el código. Para obtener más información, vea «Uso de la revisión de código de GitHub Copilot».

Los comentarios que se generan basados en una instrucción de codificación incluirán un mensaje, donde se resalta su origen.

Captura de pantalla de un comentario generado a partir de una instrucción de codificación personalizada.

Ejemplos de instrucciones de codificación

Ejemplo 1: Evitar el uso de números mágicos

Título: Avoid using magic numbers

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

Patrones de rutas de acceso: **/*.py

Ejemplo 2: No usar SELECT * en consultas SQL

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

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

Patrones de ruta de acceso: Ninguno (se aplica a todos los tipos de archivo, ya que las consultas SQL se pueden incrustar en el código).

Ejemplo 3: Usar fetch para solicitudes HTTP

Título: Use `fetch` for HTTP requests

Descripción: Use `fetch` for HTTP requests, not `axios` or `superagent` or other libraries.

Patrones de rutas de acceso: **/*.ts, **/*.js, **/*.jsx, **/*.tsx

Ejemplo 4: Etiquetar siempre las métricas con el entorno actual

Título: Always tag metrics with the current environment

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

Patrones de rutas de acceso: */*.go, */*.java