ここ２ヶ月くらいのコードレビューのまとめ

なぜ書こうと思ったか

goのコードレビューにてレビュアーの方からコードの書き方/設計について様々な指摘を頂き、忘れないためにも備忘録として書く。

本題

• 業務ステップを思い浮かべる。思い浮かんだ業務ステップがメインメソッドの処理に書くべきことである。逆に他の細かい処理をメインメソッドに書くべきではない。（メイン処理を目立たせたいため）
• メイン処理に関係ない処理は大抵メイン処理の前段階でバリデーション/実装できる。
• 意味を伝えなければならない場合と伝えなくても良い場合で変数命名を変えるようにする。 ex. スコープが広い変数についてはその変数名が何を表しているか表現するようにするが、スコープが極端に狭い変数名(２、３行)については省略した命名でも良い。これはgoの慣習？
• １ファイル/1パッケージ/1プロジェクトで統一された命名規則を使用する。
• structは単一責務を負う。データ取得用のメンバ変数やビジネスロジックに使用するメンバ変数が混在してはならない。
• 無闇に空行を作らない。データ取得とビジネスロジックの境目など限定的に作り、空行にも意味を持たせる。