今回の内容は、コードをきれいに保つためのチェックリストです。
プログラムの品質を高く維持するためには、失敗しない手順を作り、必ずその手順を守ることが大切だとお伝えしました。
意外に思うかもしれませんが、あなたがコードを書く際の癖は知らず知らずのうちに品質に大きく影響します。
- リストにアクセスする際に、list[0] などインデックス番号を直接指定した結果、index out of range エラーが発生した
- オブジェクトの初期化をし忘れたがために、null reference エラーが発生した
これらのエラーは一例ですが、プログラマーの悪い癖が原因で発生することが大半です。そして癖によるエラーを起こすのは、非常に恥ずかしいことだということも覚えておきましょう。
どれだけ良いプログラムを仕上げても、悪い癖が抜けなければ品質を安定させることはできません。
ここに挙げるチェックリストを活用しながら、自分の癖を直していきましょう。
ここに挙げるチェックリストは、C#をベースに作成されています。
あなたが使用している言語とは一部当てはまらないチェック項目もあるかもしれませんが、適宜読み替えて使ってください。
悪い癖をなくすためのチェックリスト
ファイル分割、クラス分割、メソッド定義に関するチェックリスト
- 名前空間が正しい値になっている
- 指定のフォルダにファイルを配置している
- クラスの参照範囲(public,privateなど)は適切に指定している
- 不必要な静的クラスを作成していない
- 共通クラスに、自分が作成した関数専用のメソッドを記述していない
- クラスのコンストラクタに適切な引数を渡している
- 関数の引数に不要な引数は存在していない
- 関数の戻り値に不要な値は存在していない
- 単一責任の原則を守ってクラスやメソッドの分割をできている
- 不要なusingはない
- すでに存在している共通関数を積極的に活用した
命名規則、見た目に関するチェックリスト
- クラス名のキャメルケースを正しく指定している
- クラス名は、一目で処理の概要が分かる名前になっている
- メソッド名のキャメルケースを正しく指定している
- メソッド名は、一目で処理の概要が分かる名前になっている
- フィールド変数名のキャメルケースを正しく指定している
- フィールド変数名は、一目で処理の概要が分かる名前になっている
- 変数名のキャメルケースを正しく指定している
- 変数名は、一目で処理の概要が分かる名前になっている
- 定数名のキャメルケースを正しく指定している
- 定数名は、一目で処理の概要が分かる名前になっている
- フラグの変数名は、isXxxやhasXxxなど、trueであればどちらの状態かが明確になる名前になっている
- 正しくインデントされている
- 不要なコメントがない
- コメントに誤りがない
- 不要な改行がない(意図をもって改行している)
- 1文が長い場合は、適度に改行している
処理制御に関するチェックリスト
- if分岐を網羅している(elseのケースを漏れなく考慮している)
- switchのcaseを網羅している
- 不要なループを実装していない
- ループ内の1行目の考慮を正しくできている
- ループの最終行の考慮を正しくできている
- ループの初期値、終了値、増分値を正しく指定している
- 無限ループには絶対にならない
- オブジェクトを使う前には、必ずnewしている
- リストの変数に配列番号を指定する場合は、必ず配列の対象行が存在しているかの分岐を記載している
- 呼び出した関数の戻り値を見てエラー時の考慮もできている
- 処理が正常したかどうかを示す変数の初期値は、「失敗」を表す値になっている
- 処理が正常したかどうかを示す変数の値は、成功のときのみ「成功」を表す値になっている
- ラムダ式の外で出来る演算を、ラムダ式の中でやっていない(処理速度に影響する)
- リストへの値のセットは、アサインではなくAddRange関数を使っている
その他のチェックリスト
- 不要なログを出力していない
- エラー時のハンドリングを正しくできている
- エラーログは、エラーの内容と発生箇所が分かるように出力している
- DBアクセス時は、必ずコネクションをクローズしている
- DBアクセス時は、適切な単位でトランザクションを定義している
- DBアクセス時のトランザクションは、必ず明示的にCommitまたはRollbackしている
- ファイルアクセス時は、必ずファイルを閉じている
自分が成長するためのチェックリスト
- プロとして人に見せても恥ずかしくないコードを書けた
- 前回開発したコードと比べて、より良いコードを書けた(どこが良くなったのかを具体的に記述する)
- (既存のコードの改修をする場合)元々あるコードのリファクタリングをした
- 前回した失敗を防ぐために、作業手順を改善した(改善した手順を具体的に記述する)
- 次回のコーディングで改善する手順が明確になっている(改善する手順を具体的に記述する)
まとめ
上司にコードレビューをしてもらう前には、このチェックリストに沿って毎回セルフチェックしましょう。
私が多くの人のコードをレビューしてきた経験を踏まえると、自分で出来ていると思ってチェックをONにしたポイントでも、実際できていないということが多々あります。
インデントがずれている、変数名が規則通りになっていない、処理結果が正常かどうかを見ていないなどの誤りはほぼ必ず1つはあります。
これらを「ミス」として片づけるのではなく、しっかりと振り返って再発防止策を立てることです。
この地道な積み重ねが、優秀なプログラマーという評価へとつながっていきます。
そして、自分が何も考えずにきれいなコードを書けるようになると、より重要なことを考えるために脳を使うことができるようになります。結果、コードを仕上げるスピードが驚くほどUPするでしょう。
体で覚えるぐらい、何度も何度も癖付けましょう。