ソースコードの話

明けましておめでとうございます。
EC部開発部のコウユウショウです。

今回の新人ブログは引き続き自分が携わっている初の開発項目について
話したいと思います。

前回のブログで言った通り、設計書を書くの部分を終えて、実装の部分に進みたいと思います。
出来る限り将来自分が書いたソースコードを編集するエンジニアに
迷惑をかけないようにするため、いつも可読性と保守性が高いコードを
書くことを心がけています。
（心にかけているんですが、ゴリ押しコードばっかりでした…申し訳ない…)

では、開発の初心者は、どうやれば良いソースコードを書けるだろう？
わからないので調べて纏めてみました！

１．フォーマットの統一
研修の初期も教えてくれました、WSのソースコードが
既定のフォーマットやインデンテーションがあります。
例えば、変数名を設定するとき大文字や小文字の基準（deliverySpecifiedHours）
と条件式の()に必ず空白スペースを入れないといけないなどのフォーマットがあります。
ネットで調べたソースコード例に例えると、

いい例：
void getStudents(id) {
if (id != null) {
go_and_get_the_student();
} else {
abort_mission();
}
}

悪い例：
void getStudents(id) {
if (id != null) {
go_and_get_the_student();}
else
{
abort_mission();
}
}

悪い例のソースコードの可読性がかなり低いでしょうかね…
（Eclipseの開発環境でCtrl + Shift + F で自動的にソースコードのフォーマットが整理されるけど、
たまに不具合が発生しますので、手動で修正する力が必要…)

２．わかりやすい変数名とメソッド名を名付けること
ものすごく膨大なプロジェクト開発のソースコードの中に数えられないぐらいの変数が存在しています。
なので、わかりやすい変数名は大事です。
特に自分で変数名を決めないといけない場合、どの変数名にすると、だれでも理解できるのか課題になりました。

例えば以下いくつかネットから悪い変数名の例：
✖ data　→　何のデータ？
✖ var　→　variable（変数）の略？
✖ aaa　→　論外
✖ expenditure　→　意味を調べないと分からない
✖ taro　→　誰かの名前？

３．ソースコードを過度の簡潔化はしない
ソースコードが短いほど良いとの錯覚がよくあります。
確かにスマートな書き方で実装できれば満足しますが、
ソースコードが簡潔すぎると可読性がなかなか落ちます。

学生の頃にプロジェクト開発グループのメンバーからソースコードを渡されました。
自分が新し機能を追加したいですが、ソースコードの中に大量なラムダ式と共通変数があって、
結局ソースファイルの最初から最後まで読み切らないと理解できない事情がありました。（一方、本人の理解力が不足かも）

ソースコードの理解力は個々に違うので、
できる限り誰でも簡単に理解、追加、削除できるように書いたほうがいいだろうと最近検討しています。（ゴリ押しソースコードも悪くはないかも）

いかがでしょうか。
今回の良いソースコード基準の話はここまでです。
今年もソースコードの中にバグがないよう祈ります。

本年もどうぞよろしくお願いいたします。