kotlin-development

Kotlin 開発のベストプラクティス

一般原則

• すべてのコードとドキュメントには英語を使用します
• すべての変数と関数の型を必ず宣言します
• any 型は避け、必要な型を作成します
• 関数本体には空行を入れません

命名規則

大文字・小文字の規則

• PascalCase：クラス、インターフェース、列挙型
• camelCase：変数、関数、メソッド、パラメーター
• UPPERCASE：環境変数、定数
• underscores_case：ファイル、ディレクトリ

命名のガイドライン

• 各関数は動詞（get、set、create、update、delete など）で始めます
• 略語ではなく完全な単語を使用します
  • 使用可能な略語：API、URL、ループの i/j、err、ctx、req/res/next
• マジックナンバーは避け、代わりに定数を定義します
• ブール値の変数には接頭辞を付けます：isLoading、hasError、canDelete

関数の設計

サイズと責務

• 関数は20命令未満にします
• 各関数は単一の責務を持つようにします
• 複雑さが増した場合は、ロジックをユーティリティ関数に抽出します

関数の命名

• 動作を表す動詞ベースの名前を使用します
• ブール値を返す関数には、is、has、can を接頭辞として付けます
• 値を返さない関数には、execute、save、send などの動作を表す動詞を接頭辞として付けます

ネストの削減

• エッジケースを最初に処理するため、早期リターンを使用します
• ネストされたロジックは別の関数に抽出します
• ループを最小限に抑えるため、高階関数（map、filter、reduce）を活用します
• 単純な処理にはアロー関数を優先し、それ以外の場合は名前付き関数を使用します

パラメーター

• null チェックの代わりにデフォルトパラメーターを使用します
• 関数に複数のパラメーターがある場合は、オブジェクトにまとめます（RO-RO パターン）
• パラメーターリストは短く保ちます（最大3～4個）

データの取り扱い

データクラス

• データ構造にはデータクラスを使用します
• プリミティブ型がドメイン概念を表す場合は、複合型にカプセル化します
• データクラス内でデータを検証します

不変性

• データには不変性を優先します
• 変更されない変数には val を使用します
• 可能な場合は不変コレクションを使用します
• 既存のインスタンスを変更するのではなく、新しいインスタンスを作成します

クラスとオブジェクト

サイズのガイドライン

• クラスは200命令未満にします
• public メソッドは10個未満にします
• プロパティは10個未満にします

設計原則

• SOLID 原則に従います
• 継承よりもコンポジションを優先します
• 抽象化にはインターフェースを使用します
• クラスは単一の責務に集中させます

例外処理

例外を使用する場合

• 例外は本当に予期しないエラーに限定します
• 制御フローに例外を使用しません
• 次の場合にのみ例外をキャッチします：
  • 想定される問題を修正する
  • 再スローする前にコンテキストを追加する

ベストプラクティス

• ドメイン固有のエラーにはカスタム例外型を作成します
• 意味のあるエラーメッセージを含めます
• 適切なレベルで例外をログに記録します

テスト

ユニットテスト

• Arrange-Act-Assert の規約に従います
• すべての public 関数にユニットテストを作成します
• 依存関係にはテストダブル（モック、スタブ、フェイク）を使用します
• 動作を説明する、具体的な名前をテストに付けます

受け入れテスト

• Given-When-Then の規約に従います
• ユーザー向けの動作やシナリオをテストします
• テストは独立性と再現性を保ちます

コードの構成

• 関連する機能をまとめます
• ファイルの役割を明確にし、一貫性を保ちます
• パッケージ／モジュールを使用して、機能またはレイヤーごとにコードを整理します
• プロジェクト全体で一貫したファイル構成を維持します