Jeśli masz niestandardowy zestaw sprawdzonych metod lub konwencji, które Gemini Code Assist w GitHubie ma sprawdzać lub stosować podczas inspekcji kodu, możesz dodać plik styleguide.md Markdown do .gemini/ folderu głównego repozytorium.
Użytkownicy wersji Enterprise Gemini Code Assist w GitHubie mogą korzystać z konsoli Google Cloud, aby dodawać informacje o stylu, które będą używane w wielu repozytoriach.
W obu przypadkach przewodnik dotyczący stylu jest traktowany jako zwykły plik Markdown i rozszerza standardowy prompt używany przez Gemini Code Assist w GitHubie.
Standardowe wzorce inspekcji kodu
Jeśli nie określono niestandardowych przewodników dotyczących stylu, Gemini Code Assist koncentruje się na tych głównych kategoriach obszarów, w których przeprowadza inspekcję kodu:
Prawidłowość: sprawdza, czy kod działa zgodnie z zamierzeniami i obsługuje przypadki brzegowe, wykrywa błędy logiczne, wyścigi lub nieprawidłowe użycie interfejsu API.
Wydajność: identyfikuje potencjalne wąskie gardła wydajności lub obszary wymagające optymalizacji, takie jak nadmierne pętle, wycieki pamięci, nieefektywne struktury danych, zbędne obliczenia, nadmierne rejestrowanie i nieefektywne manipulowanie ciągami.
Łatwość utrzymania: ocenia czytelność kodu, jego modułowość oraz zgodność z idiomami językowymi i sprawdzonymi metodami. Wskazuje nieprawidłowe nazwy zmiennych, funkcji i klas, brak komentarzy lub dokumentacji, złożony kod, duplikowanie kodu, niespójne formatowanie i magiczne liczby.
Bezpieczeństwo: identyfikuje potencjalne luki w zabezpieczeniach związane z obsługą danych lub weryfikacją danych wejściowych, takie jak niebezpieczne przechowywanie danych wrażliwych, ataki typu injection, niewystarczające kontrole dostępu, fałszowanie żądań z innej witryny (CSRF) i niebezpieczne bezpośrednie odwołania do obiektów (IDOR).
Różne: podczas sprawdzania żądania scalenia brane są pod uwagę inne tematy, takie jak testowanie, wydajność, skalowalność, modułowość i możliwość ponownego użycia oraz rejestrowanie i monitorowanie błędów.
Przykładowy poradnik stylu
Plik styleguide.md nie ma zdefiniowanego schematu. Jest to opis w języku naturalnym, który określa, jak Gemini Code Assist ma przeprowadzać weryfikację kodu. Ten fragment kodu to przykład pliku styleguide.md:
# Company X Python Style Guide
## Introduction
This style guide outlines the coding conventions for Python code developed at
Company X. It's based on PEP 8, but with some modifications to address
specific needs and preferences within our organization.
## Key Principles
* **Readability:** Code should be easy to understand for all team members.
* **Maintainability:** Code should be easy to modify and extend.
* **Consistency:** Adhering to a consistent style across all projects
improves collaboration and reduces errors.
* **Performance:** While readability is paramount, code should be efficient.
## Deviations from PEP 8
### Line Length
* **Maximum line length:** 100 characters (instead of PEP 8's 79).
* Modern screens allow for wider lines, improving code readability in
many cases.
* Many common patterns in our codebase, like long strings or URLs, often
exceed 79 characters.
### Indentation
* **Use 4 spaces per indentation level.** (PEP 8 recommendation)
### Imports
* **Group imports:**
* Standard library imports
* Related third party imports
* Local application/library specific imports
* **Absolute imports:** Always use absolute imports for clarity.
* **Import order within groups:** Sort alphabetically.
### Naming Conventions
* **Variables:** Use lowercase with underscores (snake_case): `user_name`, `total_count`
* **Constants:** Use uppercase with underscores: `MAX_VALUE`, `DATABASE_NAME`
* **Functions:** Use lowercase with underscores (snake_case): `calculate_total()`, `process_data()`
* **Classes:** Use CapWords (CamelCase): `UserManager`, `PaymentProcessor`
* **Modules:** Use lowercase with underscores (snake_case): `user_utils`, `payment_gateway`
### Docstrings
* **Use triple double quotes (`"""Docstring goes here."""`) for all docstrings.**
* **First line:** Concise summary of the object's purpose.
* **For complex functions/classes:** Include detailed descriptions of
parameters, return values, attributes, and exceptions.
* **Use Google style docstrings:** This helps with automated documentation generation.
```python
def my_function(param1, param2):
"""Single-line summary.
More detailed description, if necessary.
Args:
param1 (int): The first parameter.
param2 (str): The second parameter.
Returns:
bool: The return value. True for success, False otherwise.
Raises:
ValueError: If `param2` is invalid.
"""
# function body here
```
### Type Hints
* **Use type hints:** Type hints improve code readability and help catch
errors early.
* **Follow PEP 484:** Use the standard type hinting syntax.
### Comments
* **Write clear and concise comments:** Explain the "why" behind the code,
not just the "what".
* **Comment sparingly:** Well-written code should be self-documenting where
possible.
* **Use complete sentences:** Start comments with a capital letter and use
proper punctuation.
### Logging
* **Use a standard logging framework:** Company X uses the built-in
`logging` module.
* **Log at appropriate levels:** DEBUG, INFO, WARNING, ERROR, CRITICAL
* **Provide context:** Include relevant information in log messages to aid
debugging.
### Error Handling
* **Use specific exceptions:** Avoid using broad exceptions like `Exception`.
* **Handle exceptions gracefully:** Provide informative error messages and
avoid crashing the program.
* **Use `try...except` blocks:** Isolate code that might raise exceptions.
## Tooling
* **Code formatter:** [Specify formatter, e.g., Black] - Enforces
consistent formatting automatically.
* **Linter:** [Specify linter, e.g., Flake8, Pylint] - Identifies potential
issues and style violations.
Zarządzanie przewodnikami po stylu w wielu repozytoriach
Jeśli masz wersję dla przedsiębiorstw Gemini Code Assist w GitHubie, możesz zastosować jeden przewodnik po stylu do wielu repozytoriów. Repozytoria są pogrupowane według połączenia Developer Connect, a zarządzanie ich wspólnym przewodnikiem po stylu odbywa się w konsoli Google Cloud.
Jeśli repozytorium jest zarządzane w ramach grupy, ale ma też własny plik styleguide.md, plik styleguide.md repozytorium jest łączony z przewodnikiem po stylu grupy.
Poniższe kroki pokazują, jak użytkownicy wersji Enterprise mogą kontrolować jeden przewodnik po stylu w wielu repozytoriach. Zakładamy, że Gemini Code Assist w GitHubie jest już skonfigurowany.
W konsoli Google Cloud otwórz stronę Gemini Code Assist Agenci i narzędzia.
W sekcji Agenci znajdź kartę Zarządzanie kodem źródłowym w Code Assist i kliknij Zaawansowane.
Otworzy się panel Edytuj Code Assist do zarządzania kodem źródłowym.
W tabeli Połączenia kliknij nazwę połączenia, do którego chcesz zastosować przewodnik po stylu.
Otworzy się strona z informacjami o połączeniu.
Na karcie Przewodnik po stylu dodaj przewodnik po stylu, którego mają używać repozytoria powiązane z tym połączeniem.
Kliknij Zapisz.
Co dalej?
- Zmodyfikuj konfigurację Gemini Code Assist w GitHubie.