คู่มือแนะนำรูปแบบการตรวจสอบโค้ด

หากคุณมีชุดแนวทางปฏิบัติแนะนำหรือแบบแผนที่กำหนดเองซึ่งต้องการให้ Gemini Code Assist บน GitHub ตรวจสอบหรือปฏิบัติตามเมื่อทำการตรวจสอบโค้ด คุณสามารถเพิ่มstyleguide.mdไฟล์ Markdown ไปยัง.gemini/โฟลเดอร์รูทของที่เก็บได้ ผู้ใช้ Gemini Code Assist บน GitHub เวอร์ชันองค์กรสามารถใช้คอนโซล Google Cloud เพื่อเพิ่มข้อมูลคู่มือการเขียนสำหรับใช้ในที่เก็บหลายแห่งได้ ในทั้ง 2 กรณี ระบบจะถือว่าคู่มือสไตล์เป็นไฟล์ Markdown ปกติ และ ขยายพรอมต์มาตรฐานที่ Gemini Code Assist ใน GitHub ใช้

รูปแบบการตรวจสอบโค้ดมาตรฐาน

เมื่อไม่ได้ระบุคู่มือสไตล์ที่กำหนดเอง หมวดหมู่หลักของ พื้นที่ที่ Gemini Code Assist มุ่งเน้นการตรวจสอบโค้ดมีดังนี้

  • ความถูกต้อง: ตรวจสอบว่าโค้ดทํางานตามที่ตั้งใจไว้และจัดการกรณีขอบ ตรวจสอบข้อผิดพลาดด้านตรรกะ สภาวะการแข่งขัน หรือการใช้ API ที่ไม่ถูกต้อง

  • ประสิทธิภาพ: ระบุจุดคอขวดด้านประสิทธิภาพที่อาจเกิดขึ้นหรือพื้นที่ที่ต้อง เพิ่มประสิทธิภาพ เช่น ลูปที่มากเกินไป หน่วยความจำรั่ว โครงสร้างข้อมูลที่ไม่มีประสิทธิภาพ การคำนวณที่ซ้ำซ้อน การบันทึกที่มากเกินไป และการจัดการสตริงที่ไม่มีประสิทธิภาพ

  • การบํารุงรักษา: ประเมินความสามารถในการอ่านโค้ด ความเป็นโมดูล และการยึดมั่นใน สำนวนภาษาและแนวทางปฏิบัติแนะนำ ระบุการตั้งชื่อตัวแปร ฟังก์ชัน และคลาสที่ไม่ดี การไม่มีความคิดเห็นหรือเอกสารประกอบ โค้ดที่ซับซ้อน การทำโค้ดซ้ำ การจัดรูปแบบที่ไม่สอดคล้องกัน และตัวเลขมหัศจรรย์

  • ความปลอดภัย: ระบุช่องโหว่ที่อาจเกิดขึ้นในการจัดการหรือการป้อนข้อมูล การตรวจสอบความถูกต้อง เช่น การจัดเก็บข้อมูลที่ละเอียดอ่อนอย่างไม่ปลอดภัย การโจมตีแบบแทรก การควบคุมการเข้าถึงที่ไม่เพียงพอ การปลอมแปลงคำขอข้ามเว็บไซต์ (CSRF) และการอ้างอิงออบเจ็กต์โดยตรงที่ไม่ปลอดภัย (IDOR)

  • อื่นๆ: ระบบจะพิจารณาหัวข้ออื่นๆ เมื่อตรวจสอบคำขอ Pull เช่น การทดสอบ ประสิทธิภาพ ความสามารถในการปรับขนาด ความเป็นโมดูล และการนำกลับมาใช้ใหม่ รวมถึงการบันทึกและการตรวจสอบข้อผิดพลาด

ตัวอย่างคู่มือแนะนำ

ไฟล์ styleguide.md ไม่มีสคีมาที่กำหนด แต่เป็นคำอธิบายภาษาธรรมชาติเกี่ยวกับวิธีที่คุณต้องการให้ Gemini Code Assist จัดโครงสร้างการตรวจสอบโค้ด ข้อมูลโค้ดต่อไปนี้เป็นตัวอย่างของไฟล์ 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.

จัดการคู่มือสไตล์ในที่เก็บหลายแห่ง

หากคุณมี Gemini Code Assist บน GitHub เวอร์ชันองค์กร คุณจะใช้คำแนะนำ เกี่ยวกับสไตล์กับที่เก็บหลายรายการได้ ที่เก็บจะจัดกลุ่มตามการเชื่อมต่อ Developer Connect และการจัดการคู่มือสไตล์ร่วม จะทำผ่านคอนโซล Google Cloud

หากมีการจัดการที่เก็บเป็นส่วนหนึ่งของกลุ่ม แต่ก็มีไฟล์ styleguide.md ของตัวเองด้วย ระบบจะรวม styleguide.md ของที่เก็บเข้ากับ คู่มือสไตล์ของกลุ่ม

ขั้นตอนต่อไปนี้แสดงวิธีที่ผู้ใช้เวอร์ชันองค์กรสามารถควบคุมคู่มือ สไตล์หนึ่งๆ ในที่เก็บหลายแห่ง ขั้นตอนเหล่านี้ถือว่าคุณได้ตั้งค่า Gemini Code Assist ใน GitHub ไว้ก่อนหน้านี้แล้ว

  1. ในคอนโซล Google Cloud ให้ไปที่หน้าเอเจนต์และเครื่องมือของ Gemini Code Assist

    ไปที่เอเจนต์และเครื่องมือ

  2. ในส่วนเอเจนต์ ให้ค้นหาการ์ดการจัดการซอร์สโค้ดของ Code Assist แล้วคลิกขั้นสูง

    บานหน้าต่างแก้ไขการจัดการซอร์สโค้ดของ Code Assist จะเปิดขึ้น

  3. ในตารางการเชื่อมต่อ ให้คลิกชื่อการเชื่อมต่อที่คุณ ต้องการใช้คู่มือสไตล์

    หน้ารายละเอียดของการเชื่อมต่อจะเปิดขึ้น

  4. ในแท็บคู่มือสไตล์ ให้เพิ่มคู่มือสไตล์ที่ต้องการให้ที่เก็บ ที่เชื่อมโยงกับการเชื่อมต่อนี้ใช้

  5. คลิกบันทึก

ขั้นตอนถัดไป