いきなりサンプルです。
自由に書き換えて使用してください。
# 【プロジェクト名】Pythonコーディング規約
## 1. はじめに
本文書は【プロジェクト名】におけるPythonコーディングの規約を定めるものです。本規約は、コードの可読性、保守性、一貫性を高めることを目的としています。
## 2. 基本方針
- PEP 8に準拠することを基本とします。
- 本規約で特に定めのない事項についてはPEP 8に従ってください。
- 本規約はプロジェクトの進行に伴い、適宜更新されることがあります。
## 3. ファイル形式
- 文字エンコーディングはUTF-8を使用します。
- 改行コードはLF（\n）を使用します。
- ファイル末尾には空行を1行入れてください。
## 4. インデント
- インデントには4つのスペースを使用します。
- タブ文字は使用しないでください。
## 5. 行の長さ
- 1行の最大長は100文字とします。
- docstringやコメントの場合は72文字を超えないようにしてください。
## 6. 命名規則
### 6.1 変数名
- スネークケース（例: user_name）を使用します。
- 1文字の変数名は避けてください（ループカウンタを除く）。
### 6.2 関数名
- スネークケース（例: calculate_total）を使用します。
### 6.3 クラス名
- パスカルケース（例: UserAccount）を使用します。
### 6.4 定数
- すべて大文字のスネークケース（例: MAX_RETRY_COUNT）を使用します。
### 6.5 モジュール名
- すべて小文字（例: user_management）を使用します。
## 7. インポート
- インポートは以下の順序で記述し、それぞれのグループの間に1行空けてください：
1. 標準ライブラリ
2. サードパーティライブラリ
3. ローカルアプリケーション/ライブラリ
- `from X import *` の使用は避けてください。
## 8. コメント
- コードの意図が明確でない場合にのみコメントを追加してください。
- コメントは常に最新の状態に保ってください。
- 日本語コメントを使用する場合は、コードブロックの前に記述してください。
## 9. ドキュメンテーション
- すべての関数、クラス、メソッドにdocstringを記述してください。
- docstringはGoogle形式を使用します。
例:
<pre>
def calculate_area(radius: float) -> float:
"""円の面積を計算します。
Args:
radius (float): 円の半径
Returns:
float: 円の面積
Raises:
ValueError: 半径が負の値の場合
"""
if radius < 0:
raise ValueError("半径は正の値である必要があります")
return math.pi * radius ** 2
</pre>
## 10. 例外処理
- 具体的な例外をキャッチしてください（`except Exception:`の使用は避ける）。
- 例外をキャッチした場合は適切なエラーメッセージをログに記録してください。
## 11. 型ヒント
- すべての関数とメソッドに型ヒントを付けてください。
- 複雑な型ヒントには`typing`モジュールを使用してください。
## 12. テスト
- すべての新しい機能に対してユニットテストを作成してください。
- テストカバレッジは最低80%を維持してください。
## 13. バージョン管理
- コミットメッセージは以下の形式に従ってください：
<pre>
[タイプ] 簡潔な説明
詳細な説明（必要な場合）
</pre>
タイプは以下のいずれかを使用：
- feat: 新機能
- fix: バグ修正
- docs: ドキュメントのみの変更
- style: コードの意味に影響を与えない変更（空白、フォーマット、セミコロンの欠落など）
- refactor: バグ修正でも新機能の追加でもないコード変更
- test: 不足しているテストの追加や既存のテストの修正
- chore: ビルドプロセスやドキュメント生成などの補助ツールやライブラリの変更
## 14. コード品質ツール
- flake8を使用してコードの品質をチェックしてください。
- pylintスコアは最低8.0を維持してください。
## 15. セキュリティ
- 機密情報（パスワード、APIキーなど）をハードコードしないでください。
- ユーザー入力は必ず検証し、適切にエスケープしてください。
## 16. パフォーマンス
- 大きなデータセットを扱う場合は、ジェネレータやイテレータを使用してください。
- 頻繁に実行される処理では、リスト内包表記やジェネレータ式を活用してください。
## 17. 規約の適用
- コードレビューの際に本規約への準拠を確認してください。
- CIプロセスに静的解析ツールを組み込み、自動チェックを実施してください。
## 18. 規約の更新
- 本規約の変更提案は【担当者名/チーム名】に提出してください。
- 規約の更新は定期的（四半期ごと）に検討し、必要に応じて改訂します。
以上
プロジェクトの具体的なニーズや既存の慣行に合わせて適宜調整してください。
また、チームメンバーからのフィードバックをもらい、全員が理解し、遵守できる規約になるようにブラッシュアップしてください。