Kod incelemesi stil kılavuzu

GitHub'da Gemini Code Assist'in kod incelemesi yaparken kontrol etmesini veya uymasını istediğiniz özel bir dizi en iyi uygulama ya da kuralınız varsa deponuzun .gemini/ kök klasörüne styleguide.md Markdown dosyası ekleyebilirsiniz. GitHub'daki Gemini Code Assist'in kurumsal sürümünü kullananlar, Google Cloud Console'u kullanarak birden fazla depoda kullanılmak üzere stil kılavuzu bilgileri ekleyebilir. Her iki durumda da stil kılavuzu normal bir Markdown dosyası olarak değerlendirilir ve GitHub'da Gemini Code Assist'in kullandığı standart istemi genişletir.

Standart kod inceleme kalıpları

Özel stil kılavuzları belirtilmediğinde Gemini Code Assist'in kod incelemesine odaklandığı başlıca alan kategorileri şunlardır:

  • Doğruluk: Kodun amaçlandığı gibi çalıştığından ve uç durumları ele aldığından emin olur, mantık hatalarını, yarış durumlarını veya yanlış API kullanımını kontrol eder.

  • Verimlilik: Aşırı döngüler, bellek sızıntıları, verimsiz veri yapıları, gereksiz hesaplamalar, aşırı günlük kaydı ve verimsiz dize işleme gibi olası performans darboğazlarını veya optimizasyon alanlarını belirler.

  • Sürdürülebilirlik: Kodun okunabilirliğini, modülerliğini ve dil deyimlerine ve en iyi uygulamalara uygunluğunu değerlendirir. Değişkenler, işlevler ve sınıflar için kötü adlandırma, yorum veya dokümantasyon eksikliği, karmaşık kod, kod tekrarı, tutarsız biçimlendirme ve sihirli sayıları hedefler.

  • Güvenlik: Veri işleme veya giriş doğrulama işlemlerindeki olası güvenlik açıklarını (ör. hassas verilerin güvenli olmayan şekilde depolanması, ekleme saldırıları, yetersiz erişim denetimleri, siteler arası istek sahteciliği (CSRF) ve güvenli olmayan doğrudan nesne referansları (IDOR)) tanımlar.

  • Çeşitli: Pull isteği incelenirken test, performans, ölçeklenebilirlik, modülerlik ve yeniden kullanılabilirlik ile hata günlük kaydı ve izleme gibi diğer konular da dikkate alınır.

Stil kılavuzu örneği

styleguide.md dosyasında tanımlanmış bir şema yok. Bunun yerine, Gemini Code Assist'in kod incelemelerini nasıl yapılandırmasını istediğinize dair doğal dil açıklamasıdır. Aşağıdaki kod snippet'i bir styleguide.md dosyası örneğidir:

# 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.

Stil kılavuzlarını birden fazla depoda yönetme

GitHub'da Gemini Code Assist'in kurumsal sürümüne sahipseniz birden fazla depoya tek bir stil kılavuzu uygulayabilirsiniz. Depolar, bir Developer Connect bağlantısına göre gruplandırılır ve toplu stil kılavuzlarının yönetimi Google Cloud Console üzerinden gerçekleştirilir.

Bir depo, bir grubun parçası olarak yönetiliyorsa ancak kendi styleguide.md dosyası da varsa deponun styleguide.md dosyası grup stil kılavuzuyla birleştirilir.

Aşağıdaki adımlarda, kurumsal sürüm kullanıcılarının birden fazla depoda tek bir stil kılavuzunu nasıl kontrol edebileceği gösterilmektedir. Bu adımlarda, daha önce GitHub'da Gemini Code Assist'i ayarladığınız varsayılır.

  1. Google Cloud Console'da Gemini Code Assist Aracıları ve Araçları sayfasına gidin.

    Aracılar ve Araçlar'a gidin

  2. Aracılar bölümünde Code Assist Kaynak Kodu Yönetimi kartını bulun ve Gelişmiş'i tıklayın.

    Edit Code Assist Source Code Management (Code Assist Kaynak Kodu Yönetimi'ni Düzenle) bölmesi açılır.

  3. Bağlantılar tablosunda, stil kılavuzu uygulamak istediğiniz bağlantının adını tıklayın.

    Bağlantının ayrıntılar sayfası açılır.

  4. Stil kılavuzu sekmesinde, bu bağlantıyla ilişkili depoların kullanmasını istediğiniz stil kılavuzunu ekleyin.

  5. Kaydet'i tıklayın.

Sırada ne var?