GitHub의
Gemini Code Assist
가 코드 검토를 실행할 때 확인하거나 따라야 하는 권장사항 또는 규칙의 맞춤설정이 있는 경우 저장소의 .gemini/ 루트 폴더에
styleguide.md 마크다운 파일을 추가할 수 있습니다.
GitHub의
Gemini Code Assist 엔터프라이즈 버전 사용자는
콘솔 Google Cloud 을 사용하여 여러 저장소에서 사용할 스타일 가이드 정보를 추가할 수 있습니다.
두 경우 모두 스타일 가이드는 일반 마크다운 파일로 처리되며 GitHub의 Gemini Code Assist에서 사용하는 표준 프롬프트를 확장합니다.
표준 코드 검토 패턴
맞춤 스타일 가이드가 지정되지 않은 경우 GitHub의 Gemini Code Assist가 코드 검토에 중점을 두는 영역의 주요 카테고리는 다음과 같습니다.
정확성: 코드가 의도한 대로 작동하고 극단적인 사례를 처리하며 로직 오류, 경합 상태 또는 잘못된 API 사용을 확인합니다.
효율성: 과도한 루프, 메모리 누수, 비효율적인 데이터 구조, 중복 계산, 과도한 로깅, 비효율적인 문자열 조작과 같은 잠재적인 성능 병목 현상 또는 최적화 영역을 식별합니다.
유지보수성: 코드 가독성, 모듈성, 언어 관용구 및 권장사항 준수를 평가합니다. 변수, 함수, 클래스의 이름 지정 불량, 주석 또는 문서 부족, 복잡한 코드, 코드 중복, 일관성 없는 형식, 매직 넘버를 타겟팅합니다.
보안: 민감한 정보의 안전하지 않은 저장, 인젝션 공격, 불충분한 액세스 제어, 크로스 사이트 요청 위조 (CSRF), 안전하지 않은 직접 객체 참조 (IDOR)와 같은 데이터 처리 또는 입력 유효성 검사의 잠재적 취약점을 식별합니다.
기타: 테스트, 성능, 확장성, 모듈성 및 재사용성, 오류 로깅 및 모니터링과 같은 기타 주제는 pull 요청을 검토할 때 고려됩니다.
스타일 가이드 예
styleguide.md 파일에는 정의된 스키마가 없습니다. 대신 GitHub의 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 엔터프라이즈 버전이 있는 경우 하나의 스타일 가이드를 여러 저장소에 적용할 수 있습니다. 저장소는 Developer Connect 연결로 그룹화되며, 집단 스타일 가이드 관리는 Google Cloud 콘솔을 통해 이루어집니다.
저장소가 그룹의 일부로 관리되지만 자체 styleguide.md 파일도 있는 경우 저장소의 styleguide.md가 그룹 스타일 가이드와 결합됩니다.
다음 단계에서는 엔터프라이즈 버전 사용자가 여러 저장소에서 하나의 스타일 가이드를 제어하는 방법을 보여줍니다. 이 단계에서는 이전에 GitHub의 Gemini Code Assist를 설정했다고 가정합니다.
콘솔에서 Gemini Code Assist 에이전트 및 도구 페이지로 이동합니다. Google Cloud
에이전트 섹션에서 Code Assist 소스 코드 관리 카드를 찾아 고급 을 클릭합니다.
Code Assist 소스 코드 관리 수정 창이 열립니다.
연결 표에서 스타일 가이드를 적용할 연결의 이름을 클릭합니다.
연결의 세부정보 페이지가 열립니다.
스타일 가이드 탭에서 이 연결과 연결된 저장소에서 사용할 스타일 가이드를 추가합니다.
저장 을 클릭합니다.