코드 검토 스타일 가이드

코드 검토를 실행할 때 GitHub의 Gemini Code Assist에서 확인하거나 따라야 하는 맞춤 권장사항 또는 규칙이 있는 경우 저장소의 .gemini/ 루트 폴더에 styleguide.md 마크다운 파일을 추가하면 됩니다. GitHub의 Gemini Code Assist 엔터프라이즈 버전 사용자는 Google Cloud 콘솔을 사용하여 여러 저장소에서 사용할 스타일 가이드 정보를 추가할 수 있습니다. 두 경우 모두 스타일 가이드는 일반 마크다운 파일로 처리되며 GitHub의 Gemini Code Assist에서 사용하는 표준 프롬프트가 확장됩니다.

표준 코드 검토 패턴

맞춤 스타일 가이드가 지정되지 않은 경우 Gemini Code Assist에서 코드 검토에 중점을 두는 주요 영역은 다음과 같습니다.

• 정확성: 코드가 의도한 대로 작동하고 특이 사례를 처리하는지 확인하고, 논리 오류, 경합 상태 또는 잘못된 API 사용을 확인합니다.

• 효율성: 과도한 루프, 메모리 누수, 비효율적인 데이터 구조, 중복 계산, 과도한 로깅, 비효율적인 문자열 조작과 같은 잠재적인 성능 병목 현상 또는 최적화 영역을 식별합니다.

• 유지관리성: 코드 가독성, 모듈성, 언어 관용구 및 권장사항 준수를 평가합니다. 변수, 함수, 클래스의 이름이 부적절하거나, 주석이나 문서가 없거나, 코드가 복잡하거나, 코드 중복이 있거나, 형식이 일관되지 않거나, 매직 넘버가 있는 경우를 타겟팅합니다.

• 보안: 민감한 정보의 보안되지 않은 저장, 인젝션 공격, 불충분한 액세스 제어, 크로스 사이트 요청 위조 (CSRF), 보안되지 않은 직접 객체 참조 (IDOR)와 같은 데이터 처리 또는 입력 유효성 검사의 잠재적인 취약점을 식별합니다.

• 기타: 테스트, 성능, 확장성, 모듈성 및 재사용성, 오류 로깅 및 모니터링과 같은 기타 주제는 풀 요청을 검토할 때 고려됩니다.

스타일 가이드 예

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.

여러 저장소에서 스타일 가이드 관리

GitHub의 Gemini Code Assist 엔터프라이즈 버전을 사용하는 경우 하나의 스타일 가이드를 여러 저장소에 적용할 수 있습니다. 저장소는 개발자 Connect 연결별로 그룹화되며, 집단 스타일 가이드 관리는 Google Cloud 콘솔을 통해 이루어집니다.

저장소가 그룹의 일부로 관리되지만 자체 styleguide.md 파일도 있는 경우 저장소의 styleguide.md가 그룹 스타일 가이드와 결합됩니다.

다음 단계에서는 엔터프라이즈 버전 사용자가 여러 저장소에서 하나의 스타일 가이드를 제어하는 방법을 보여줍니다. 이 단계에서는 이전에 GitHub에서 Gemini Code Assist를 설정했다고 가정합니다.

미리보기

이 기능에는 Google Cloud 서비스별 약관의 일반 서비스 약관 섹션에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. GA 이전 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 Google Cloud 출시 단계 설명을 참고하세요.

1. Google Cloud 콘솔에서 Gemini Code Assist 에이전트 및 도구 페이지로 이동합니다.

   에이전트 및 도구로 이동

2. 에이전트 섹션에서 Code Assist 소스 코드 관리 카드를 찾아 고급을 클릭합니다.

   Code Assist 소스 코드 관리 수정 창이 열립니다.

3. 연결 표에서 스타일 가이드를 적용할 연결의 이름을 클릭합니다.

   연결 세부정보 페이지가 열립니다.

4. 스타일 가이드 탭에서 이 연결과 연결된 저장소에서 사용할 스타일 가이드를 추가합니다.

5. 저장을 클릭합니다.

다음 단계

• GitHub의 Gemini Code Assist 구성 수정