- コーディング標準とは
- ベストプラクティスとは
- なぜ標準とベストプラクティスが重要か
[[コードの可読性向上による理解促進とバグ発見の容易化]][[コードの保守性向上による変更・拡張のコスト削減]][[チーム開発における一貫性の確保とコミュニケーション円滑化]][[新規参加メンバーのオンボーディング効率化]][[ソフトウェア品質全体の向上]][[技術的負債の抑制]]
- 標準化のレベルとスコープ
[[個人レベルの標準]][[チームレベルの標準]][[組織レベルの標準]][[言語コミュニティの標準 (例: PEP 8 for Python)]]
- 標準と創造性、柔軟性のバランス
- コーディング標準と関連する概念
[[設計原則 (SOLIDなど) との関連]][[デザインパターンとの関連]][[コードレビューとの関連]]
- 命名の重要性 (名前はコードの意図を伝える最初の手段)
- 命名規則の種類と適用箇所
- ケーススタイル (Case Styles)
[[キャメルケース (camelCase)]] (例: firstName)[[パスカルケース (PascalCase / UpperCamelCase)]] (例: PersonName)[[スネークケース (snake_case)]] (例: first_name)[[スクリーミングスネークケース (SCREAMING_SNAKE_CASE)]] (例: MAX_USERS)[[ケバブケース (kebab-case)]] (例: my-variable - 主にファイル名やCSSクラス)- 言語やコミュニティごとの主流ケーススタイル
- 命名における避けるべきこと
[[短すぎる/曖昧な名前 (a, x, data, infoなど)]][[誤解を招く名前]][[型情報を含めるハンガリアン記法 (一般的に非推奨)]][[長すぎる名前 (ただし、明確さとのバランス)]][[数字で始まる名前 (多くの言語で不可)]][[予約語との衝突]][[一貫性のない命名]]
- 国際化と命名 (非ASCII文字の使用について)
- コメントの目的
[["なぜ" を説明する (コードが "何を" しているかはコード自身が示すべき)]][[複雑なロジックやアルゴリズムの解説]][[設計上の決定やトレードオフの記録]][[一時的なメモやTODO (// TODO:, // FIXME:)]][[意図的に行っている「悪い」コードの説明 (ハックやワークアラウンド)]]
- 良いコメント、悪いコメント
[[自己記述的なコード (Self-Documenting Code) を目指す]] (コメントを不要にする努力)[[冗長なコメント、自明なコメントは避ける]] (例: // iをインクリメントする\ni++;)[[コードの変更に追従しない古いコメントは害悪]][[攻撃的なコメントや不適切なジョークは避ける]][[明確で簡潔な言葉を選ぶ]]
- コメントの種類
- コメントのスタイルと言語ごとの慣習
- バージョン管理システムとコメント (コミットメッセージも一種のドキュメント)
- 条件分岐 (
if, else if, else, switch/case)
[[ネストの深さを浅く保つ (複雑性の低減)]] (ガード節、早期リターンなど)[[条件式の可読性 (複雑な条件は変数や関数に抽出)]][[ヨーダ記法 (if (null == variable)) の是非]][[switch/case文のフォールスルーの注意点と default 節の推奨]][[条件演算子 (三項演算子) の適切な使用]]
- ループ (
for, while, do-while, foreach)
[[無限ループの回避]][[ループ条件の明確化]][[ループ変数のスコープ]][[ループ内の処理のシンプルさ]][[break と continue の慎重な使用]]`[[コレクションの反復処理におけるイテレータや高階関数の活用]] (読みやすさと安全性)
- Guard Clauses)
- GOTO文の使用は原則避ける (構造化プログラミングの観点から)
- 単一責任の原則 (SRP) の適用 (関数は一つのことだけをうまくやるべき)
- 関数の長さ
[[短い関数を目指す (例: 1画面に収まる程度)]] (ただし、明確さが犠牲にならない範囲で)
- パラメータの数
- 副作用 (Side Effects)
[[副作用を明確に文書化するか、可能な限り避ける (純粋関数)]][[コマンド・クエリ分離 (CQS) の考え方]]
- 抽象度のレベルの一貫性
- 関数の凝集度 (Cohesion) (関数内の要素が密接に関連していること)
- エラー処理と戻り値
- 関数シグネチャの設計 (明確な名前、型ヒント、戻り値の型)
- (オプション) DRY原則の関数レベルでの適用 (重複コードの関数化)
- エラー処理の目的 (堅牢性、ユーザーへの適切なフィードバック、デバッグ容易性)
- 例外 (Exceptions) vs. エラーコード (Error Codes)
- 例外処理の基本 (
try-catch-finally / try-except-finally)
[[具体的な例外を捕捉する (catch (Exception e) は避ける)]][[catchブロックは適切に処理するか、再スローする (握りつぶさない)]][[finallyブロックによるリソース解放の保証 (try-with-resources / usingなど)]]
- カスタム例外 (Custom Exceptions) の作成と利用
- 検査例外 (Checked Exceptions) vs. 非検査例外 (Unchecked/Runtime Exceptions) (Javaなど)
- エラーメッセージの設計
[[明確で、問題解決に役立つ情報を含める]][[ユーザー向けと開発者向けのメッセージの分離]]
- ログ記録とエラー
- アサーション (Assertions) の利用
[[プログラムの前提条件を検査 (デバッグビルドでのみ有効な場合が多い)]]
- Either型によるエラー処理 (関数型言語スタイル)
- **(オプション) エラー処理の横断的関心事 (AOPの適用など)`
- 並行処理の課題 (複雑性、競合状態、デッドロック、ライブロック)
- スレッドセーフティ (Thread Safety)
[[共有リソースへのアクセスの同期 (Mutex, Semaphore, Monitorなど)]][[イミュータブルオブジェクトの活用]][[スレッドローカルストレージ]]
- デッドロックの予防と検出
- 競合状態の回避
- 非同期プログラミングのパターン
[[コールバック (Callbacks) とその問題点 (Callback Hell)]][[Promise / Future の利用]][[async / await 構文の利用]][[リアクティブプログラミング (Reactive Programming)]] (概要)
- リソースプーリング (スレッドプール、コネクションプール)
- キャンセル処理とタイムアウト
- 並行処理コードのテストの難しさと戦略
- 入力検証 (Input Validation)
[[全ての外部入力を信頼しない (バリデーション、サニタイズ)]][[ホワイトリスト方式 vs. ブラックリスト方式]]
- 出力エンコーディング (Output Encoding)
[[コンテキストに応じた適切なエンコーディング (HTML, SQL, JavaScriptなど) によるインジェクション対策]]
- 認証 (Authentication) と認可 (Authorization)
[[強力なパスワードポリシー、多要素認証 (MFA)]][[最小権限の原則 (Principle of Least Privilege)]]
- セッション管理 (Session Management)
- エラー処理と情報漏洩
[[詳細すぎるエラーメッセージを外部に公開しない]]
- 暗号化の実装
[[実績のある暗号アルゴリズムとライブラリの使用]][[鍵管理の重要性]]
- 依存関係のセキュリティ
[[脆弱性のあるライブラリを使用しない (SCAツールの利用)]]
- セキュアなAPI設計
- OWASP Top 10などの脆弱性リストと対策
- DAST)`
- (各言語のMOCで、その言語固有の標準（例：PEP 8）、イディオム、コミュニティ推奨プラクティスを詳述)
[[Java コーディング標準とベストプラクティス MOCへのリンク]][[Python コーディング標準とベストプラクティス MOCへのリンク]][[JavaScript コーディング標準とベストプラクティス MOCへのリンク]][[C#-コーディング標準とベストプラクティス-mocへのリンク| コーディング標準とベストプラクティス MOCへのリンク]]- (他、主要言語へのリンク)
- リンター (Linters)
[[ESLint (JavaScript), Pylint/Flake8 (Python), Checkstyle/PMD/SpotBugs (Java), RuboCop (Ruby), StyleCop/Roslyn Analyzers (C#|)]]
- フォーマッタ (Formatters)
[[Prettier (多言語対応), Black (Python), gofmt (Go), rustfmt (Rust), clang-format (C/C++/Java/etc.), Spotless (多言語対応)]]
- 静的解析ツール (Static Analysis Tools) (リンターより高度な解析)
[[SonarQube, Coverity, Veracode]]
- IDEの機能 (フォーマット、Lint連携、静的解析機能)
- CI/CDパイプラインへの統合 (自動チェックと強制)
- なぜチーム標準が必要か
- 標準策定のプロセス
[[既存の公開標準 (言語コミュニティ、Google Style Guidesなど) をベースにする]][[チームメンバー全員での議論と合意形成]][[重要な項目に絞る (過度に厳格すぎない)]][[理由や背景を明記する]]
- 標準のドキュメント化と共有
[[Wiki, Confluence, Gitリポジトリ内のMarkdownなど]]
- 標準の浸透と教育
[[新規メンバーへのオンボーディング]][[定期的な見直しと更新]]
- 標準の強制と自動化
[[リンター、フォーマッタ、CIツールの活用]][[コードレビューでの指摘]]
- 標準からの逸脱を許容する場合のプロセス
[[標準が存在しない / 誰も守らない]][[過度に厳格で開発効率を著しく下げる標準]][[理由や目的が不明な標準]][[古く、現状に合わない標準]][[ツールによる自動チェックがない、または無視される]][[標準が一方的に押し付けられる]][[「標準だから」という思考停止]]