Skip to main content

Konfigurieren von Programmierrichtlinien für den GitHub Copilot-Review

Hier erfährst du, wie du den Copilot Code Review mit benutzerdefinierten Programmierrichtlinien anpasst.

Note

Benutzerdefinierte Programmierrichtlinien sind aktuell auf ausgewählte Teilnehmende des public preview von Copilot Code Review beschränkt und nur im Rahmen eines GitHub Copilot Enterprise-Abonnements verfügbar.

Informationen zu Programmierrichtlinien

Du kannst den Copilot Code Review mit benutzerdefinierten Programmierrichtlinien in natürlicher Sprache anpassen. Weitere Informationen zum Copilot Code Review findest du unter Verwenden des GitHub Copilot-Code-Reviews.

Mit Programmierrichtlinien kann Copilot basierend auf dem individuellen Programmierstil und den Best Practices deiner Organisation Feedback geben.

Da der Copilot Code Review auf einem Large Language Model beruht, kann er helfen, Programmierrichtlinien zu erzwingen, die nicht von deinem Linter- oder statischen Analysetool abgedeckt werden.

Programmierrichtlinien werden auf Repositoryebene konfiguriert. Du kannst bis zu sechs Programmierrichtlinien pro Repository erstellen und aktivieren.

Note

  • Programmierrichtlinien funktionieren nur mit Sprachen, die vom Copilot-Review unterstützt werden. Eine Liste der unterstützten Sprachen findest du unter Verwenden des GitHub Copilot-Code-Reviews.
  • Programmierrichtlinien gelten nur für Reviews, die von Copilot durchgeführt werden. Die Richtlinien haben keine Auswirkungen auf die Copilot-Vorschläge zur Codevervollständigung oder Code, der in Copilot Chat-Antworten vorgeschlagen wird.

Empfehlungen für Programmierrichtlinien

  • Verwende einfache, klare und präzise Sprache, um deine Programmierrichtlinie zu beschreiben.
  • Beschreibe so konkret wie möglich, wonach Copilot suchen soll, d. h., was dein Code enthalten soll und was nicht.
  • Prüfe die Beispiele für Programmierrichtlinien weiter unten, um dich inspirieren zu lassen.
  • Versuche nicht, mithilfe von Programmierrichtlinien Stilrichtlinien zu erzwingen, die von deinem Linter- oder statischen Analysetool abgedeckt werden können.
  • Verwende keine Wörter, die mehrdeutig sind oder auf unterschiedliche Weise interpretiert werden können.
  • Versuche nicht, mehrere verschiedene Ideen in einer einzigen Programmierrichtlinie zusammenzufassen.

Erstellen einer Programmierrichtlinie

  1. Klicke auf der Seitenleiste im Abschnitt „Code & automation“ auf Copilot und dann auf Code review.

  2. Klicke auf Create guideline.

  3. Gib unter „Name“ den Namen der Programmierrichtlinie ein.

  4. Gib unter „Description“ eine Beschreibung der Programmierrichtlinie.Diese darf bis zu 600 Zeichen umfassen. Anhand der Beschreibung erfasst Copilot deinen Programmierstil und entscheidet, wann ein Kommentar hinterlassen werden soll.

    Wie du die Beschreibung schreibst, hat großen Einfluss auf die Qualität der Kommentare, die Copilot generiert. Hilfe beim Schreiben effektiver Programmierrichtlinien findest du weiter oben im Abschnitt Empfehlungen für Programmierrichtlinien und weiter unten im Abschnitt Beispiele für Programmierrichtlinien.

  5. Beschränke die Programmierrichtlinie optional auf bestimmte Dateitypen oder Pfade, indem du auf Add file path klickst und Pfadmuster hinzufügst.

    Mithilfe der fnmatch-Syntax kannst du Zielpfade definieren, wobei * als Platzhalter fungiert, der mit einer beliebigen Zeichenfolge übereinstimmen kann.

    Da GitHub das Flag File::FNM_PATHNAME für die Syntax File.fnmatch verwendet, entspricht das Platzhalterzeichen * nicht den Verzeichnistrennzeichen (/). qa/* entspricht z. B. allen Branches, die mit qa/ beginnen und einen einzelnen Schrägstrich enthalten, aber nicht qa/foo/bar. Nach qa kann mit qa/**/* eine beliebige Anzahl von Schrägstrichen eingeschlossen werden, um z. B. qa/foo/bar/foobar/hello-world zu entsprechen. Du kannst mit qa**/**/* auch die Zeichenfolge qa erweitern, um die Regel auszudehnen.

    Weitere Informationen zu Syntaxoptionen findest du in der Dokumentation zu fnmatch.

  6. Teste deine Programmierrichtlinie, um sicherzustellen, dass sie erwartungsgemäß funktioniert.

    1. Klicke auf Add sample.
    2. Füge dein eigenes Beispiel hinzu, oder drücke Generate code sample, um basierend auf deinem Titel und deiner Beschreibung automatisch einen Beispielcode zu generieren.
    3. Klicke auf Save, um den Beispielcode zu speichern.
    4. Teste die Programmierrichtlinie für dein Beispiel, indem du Run drückst.
  7. Speichere deine Programmierrichtlinie, und aktiviere sie, indem du auf Save guideline klickst.

Ausführen eines Review mit Programmierrichtlinien

Wenn du einen Review von Copilot anforderst, verwendet Copilot automatisch die für das Repository aktivierten Programmierrichtlinien, um deinen Code zu prüfen. Weitere Informationen findest du unter Verwenden des GitHub Copilot-Code-Reviews.

Auf einer Programmierrichtlinie basierende Kommentare enthalten eine Nachricht, in der die Quelle hervorgehoben wird.

Screenshot eines Kommentars, der aus einer benutzerdefinierten Programmierrichtlinie erstellt wurde

Beispiele für Programmierrichtlinien

Beispiel 1: Vermeiden von magischen Zahlen

Titel: Avoid using magic numbers

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

Pfadmuster: **/*.py

Beispiel 2: Vermeiden von SELECT * in SQL-Abfragen

Titel: Don't use `SELECT *` in SQL queries

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

Pfadmuster: Keines (gilt für alle Dateitypen, da SQL-Abfragen unter Umständen in Code eingebettet werden)

Beispiel 3: Verwenden von fetch für HTTP-Anforderungen

Titel: Use `fetch` for HTTP requests

Beschreibung: Use `fetch` for HTTP requests, not `axios` or `superagent` or other libraries.

Pfadmuster: **/*.ts, **/*.js, **/*.jsx, **/*.tsx

Beispiel 4: Ständiges Taggen von Metriken mit der aktuellen Umgebung

Titel: Always tag metrics with the current environment

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

Pfadmuster: */*.go, */*.java