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 のプレフィックスを付ける
• void 関数には execute、save、send などの動詞をプレフィックスとして付ける

ネストの削減

• エッジケースを最初に処理するために早期リターンを使用する
• ネストされたロジックを別の関数に抽出する
• ループを最小化するために高階関数 (map、filter、reduce) を使用する
• シンプルな操作にはアロー関数を使用し、それ以外は名前付き関数を使用する

パラメータ

• null チェックの代わりにデフォルトパラメータを使用する
• 関数が複数のパラメータを持つ場合、それらをオブジェクトに統合する (RO-RO パターン)
• パラメータリストは短く保つ (最大 3～4 パラメータ)

データ処理

データクラス

• データ構造にはデータクラスを使用する
• ドメイン概念を表すプリミティブ型をコンポジット型にカプセル化する
• データクラス内でデータを検証する

イミュータビリティ

• データではイミュータビリティを優先する
• 変更されない変数には val を使用する
• 可能な限りイミュータブルなコレクションを使用する
• 既存のインスタンスを変更するのではなく、新しいインスタンスを作成する

クラスとオブジェクト

サイズガイドライン

• クラスは 200 命令以下に保つ
• 公開メソッドは 10 個未満に制限する
• プロパティは 10 個未満に制限する

設計原則

• SOLID 原則に従う
• 継承より合成を優先する
• 抽象化にはインターフェースを使用する
• クラスは単一の責務に焦点を当てる

例外処理

例外を使用する場合

• 真に予期しないエラーのために例外を予約する
• 制御フローに例外を使用しない
• 例外をキャッチするのは以下の場合のみ
  • 予想されたイシューを修正する場合
  • 再スローする前にコンテキストを追加する場合

ベストプラクティス

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

テスト

ユニットテスト

• Arrange-Act-Assert の慣例に従う
• すべての公開関数のユニットテストを記述する
• 依存関係にはテストダブル (モック、スタブ、フェイク) を使用する
• テストを説明的に命名して、動作を文書化する

受け入れテスト

• Given-When-Then の慣例に従う
• ユーザー向けの動作とシナリオをテストする
• テストは独立しており、再現可能に保つ

コード組織

• 関連する機能をグループ化する
• ファイルはフォーカスされ、凝集度の高いものに保つ
• パッケージ/モジュールを使用してコードを機能またはレイヤーごとに整理する
• プロジェクト全体で一貫したファイル構造を維持する