体験談も含め実践に近い情報を記載します。
経験値を実践ではなく読むだけで得られるようにしていきたいと考えています。
名前の付け方
プログラミングをしていると下記項目に名前をつけると思います。
- クラス名
- 変数名
- 関数名
- テーブル名(DB)
- テーブルの項目名(DB)
名前を決める時、その名前を見て内容が分かるような名前をつけることをオススメします。
プロジェクトでプログラミングする場合、プロジェクト毎に命名規約などがあるかと思います。その際はプロジェクトの命名規約に則って名前を決めるようにしてください。
命名規約など規約がない場合は、下記規則に則って名前を決めることをオススメします。
規則名 | 説明 | 例 |
---|---|---|
キャメルケース | 単語の先頭の文字を大文字にする | loginInfo |
スネークケース | 単語と単語の間を「_(アンダーバー)」にする | login_info |
ケバブケース | 単語と単語の間を「-(ハイフン)」にする | login-info |
メリット
- コーディングした人以外が見た時に読みやすくなる
- 保守性が向上する
体験談
料金を計算するプログラムで下記内容の変数名・DB項目が設定されていた。
変数名 | DB項目名 | |
大人 | a | people3 |
中学生 | b | people1 |
小学生 | c | people2 |
仕様変更により「高校生・幼児」を追加することに…。
気をつけること
- 変数名は意味のある名前をつける
- DBの項目は可能な限り連番を含めた名前をつけないようにする
参考にするプログラムコード
インターネット上にはサンプルコードがたくさんありますが、サンプルコードを理解せずにコピペすることやめてください。
理解せずにサンプルコードを使うと下記のことが考えられます。
- 業務に沿ってない処理
- 不要な処理がありバグの原因になる
サンプルコードを参考にする場合は必ず理解した上で使うことをオススメします。
体験談
スピードを求めてサンプルコードを組み合わせて使用。仕様変更の際の打合せで処理内容の質問に対して答えられなかった。
分かりやすいコーディング
下記2点を気をつけて、シンプルにコーディングすることをオススメします。
- 自分以外がみて読みやすい
- 自分以外がみて分かりやすい
体験談
仕様変更によりプログラムの解析。仕様は簡単でしたがプログラムコードがすごく長い。簡単なことが複雑にコーディングされていて解析・検証がすごく大変な思いをした。
メリット
- 保守性が向上する
- バグが少なくなる傾向がある
コメント