Shared Knowledge MCP Server

--- description: コーディング規約 ruleId: coding-standards-01jpcvxfxgyqe2jprh9hgn6xq9 tags: ["development","coding"] aliases: ["coding-standards", "code-style-guide"] globs: ["**/*.ts", "**/*.tsx", "**/*.js", "**/*.jsx", "**/*.go", "**/*.rs", "**/*.scala"] --- # コーディング規約（Coding Standards） ## 命名規則 - クラスもしくは構造体の名前は大文字から始まるキャメルケース（PascalCase）で記述する。 - メソッド名と変数名は小文字から始まるキャメルケース（camelCase）で記述する。 - 定数は言語の標準的な規約に従って命名する。 - インタフェース名は接尾辞に「able」を付けるなど、その役割が分かる命名にする。 - ブール値を表す変数やメソッドは、is/has/can/shouldなどの接頭辞を使用する。 - ドメイン用語は一貫して使用し、略語や曖昧な名前を避ける。 ## コードスタイル - インデントは2スペースで統一する。 - 中括弧は同じ行または次の行に置くスタイルで統一する。 - 1行の長さは120文字を超えないようにする。 - メソッドの長さは20行（または適切な行数）を超えないよう努める。 - 無駄な空行や空白を含めない。 - コメントは必要に応じて追加し、コードの「なぜ」を説明する。 ## エラー処理 - 例外は使用せず、Either/Resultパターンでエラーを表現する。 - エラー型は明示的に定義し、エラーの種類を区別可能にする。 - エラーメッセージは具体的で行動可能な情報を含める。 - エラー処理を省略せず、すべてのエラーを適切に処理する。 ## コメントとドキュメント - パブリックAPIには適切なドキュメントコメントを追加する。 - 複雑なロジックには説明コメントを追加する。 - TODOコメントには課題追跡システムの参照を含める。 - コメントは自明でないコードの意図を説明するために使用する。 ## コード構成 - 1ファイルに1クラスもしくは1構造体の原則を守る。 - インポート/パッケージ文は整理して冗長なものを排除する。 - メソッドの引数は3つ以下に抑える。 - メソッドのネストレベルは3レベル以下に抑える。 - 複雑な条件式は中間変数や述語メソッドに抽出する。 ## オブジェクト指向の原則 - プリミティブ型や文字列を適切に意味のある型でラップする。 - メソッドチェインを最小限に抑え、中間オブジェクトに意味のある名前を付ける。 - クラスもしくは構造体は小さく保ち、単一責任の原則に従う。 - コレクションを返す場合は実装ではなくインタフェース型を使用する。 - 内部データを直接公開せず、適切なカプセル化を維持する。 - CQS（コマンド・クエリ分離）の原則に従う。 - 状態を変更するメソッド（コマンド）は値を返さない。 - 値を返すメソッド（クエリ）は状態を変更しない。 - デメテルの法則を厳守し、「Tell, Don't Ask」の原則に従う。 - オブジェクトの内部状態を取得して判断するのではなく、オブジェクトに適切な振る舞いを指示する。 ## 推奨プラクティス - ドメインモデル（エンティティ、値オブジェクト）は原則的に不変オブジェクトで設計する。 - ドメインサービスは純粋関数として実装し、副作用を持たないようにする。 - 以下のコンポーネントでは適切に可変性を許容する：。 - リポジトリ実装。 - ユースケース/サービスクラス。 - コントローラー。 - 設定管理クラス。 - 可変コレクションの防御的コピーを作成する。 - ヌルチェックよりもオプション型を使用する。 - 副作用のあるコードとないコードを明確に分離する。 - テストしやすいよう、依存関係は明示的に注入する。 - メッセージを送るように設計し、オブジェクトからデータを取り出して操作することを避ける。 ## 禁止プラクティス - 非表示のサイドエフェクトを含むメソッドを作らない。 - グローバル状態や静的可変状態を使用しない。 - メソッドのオーバーロードで意味的に異なる処理をしない。 - マジックナンバーや文字列リテラルを直接使用しない。 - 明示的な型変換を過度に使用しない。 - null値の使用を最小限に抑え、適切に処理する。