プログラミングのゴールは「設計書通り動くこと！」。設計書通り動いていれば、テストも通るし実際の業務にも影響を及ぼさない―。
というのは、一見正しいように見えますが、「設計書通り動くこと」というのは１００％のプログラミングではありません。１００％は「わかりやすいソースコードであること」という条件を満たして初めて達成できます。
脱「プログラミング初心者」の第１歩―。わかりやすい変数の命名方法についてまとめてみましたので、是非ご一読ください。
尚、この「わかりやすさ」は人によって、また時と場合によって異なります。また、ここで解説している命名方法だけが一つの正解ではないので、あくまでも参考程度にご覧いただけると幸いです。
①命名規約に従う
まず、第１のルールは「命名規約」に従うことです。至極当たり前な内容ですが、意外とルールを順守できていない人がいるので、１番目にあげてみました。
プライベートでプログラミングをしている人であれば別ですが、基本的に１つのシステムを作り上げる際には、そのシステム全体に共通する「命名規則」が定義されています。
・変数は「D始まりとすること」
・ローカル変数であれば「２文字目をLとすること」
など、１つのファイルにまとめれているはずなので、プログラミングに着手する前に必ず目を通すようにしましょう。
命名規約の意義
そもそも。命名規則が作られる理由は「共通化による可読性の向上」にあります。
１つのシステムを構成する際に必要なソースコードは数百・数千に上りますが、この際コードを書く人間もそれに比例して増加していきます。この際、プログラマーが独自に変数を命名していくと、その人しか意味が分からない変数が複数誕生していってしまいます。
例えば、日付を格納するローカル（１つのモジュール内でのみ利用する）変数を定義する場合でも、何通りも存在します。
LV_DATE (L/Local・V/Variavle)
DATE_L
vDATE_L
このような差異をなくし、すべての命名規則を１つに整理することで誰が見てもわかるようなソースコードにしやすくすることができます。
上記のような命名規則を用いれば、「GD_BIRTHDAY」「LD_TMP」などのようにある程度変数名をそろえることが可能です。
もし仮にプロジェクト単位ではなく、自分一人で１からプログラミングをしていく際にもあらかじめ命名規則を定義しておくのがよいでしょう。
②「意味」のある名称にする
第２のルールは、変数の名称には必ず意味を持たせることです。
LI_RESULT = LI_VALIABLE1 * LI_VALIABLE2 (結果 = 変数1 × 変数2)
ではなく、
LI_PAYMENT = LI_PRICE * GI_TAX (支払額 = 単価 × 消費税率)
としましょう、ということです。
変数に意味を持たせれば、都度設計書を見たり、前後の処理と見比べる必要もありません。
変数に意味を持たせれば「ああ、これは税込みの支払額を計算しているんだな」ということが一目でわかります。
ちょっとの工夫で、ソースコードの可読性は大幅に向上します。
変数の命名に迷ったときは：Codic
日本語を入力すると、変数の名称を提案してくれるサイトがあります。
提案結果を自分の好みになるようにカスタマイズすることもできますし、チーム全員で共用することもできます。
変数に「意味」を持たせるという観点から見た際に、非常に便利なのでぜひ利用してみてください。
③名称は具体的にする
変数名の抽象度が高いと、同じような変数が乱立してきます。
したがって、変数名はできるだけ具体度を上げて命名する必要があります。
例えば、
LD_DATE
という変数。何かの日付を表していることが分かります。が、これで何の日付を表しているかがわからず可読性が高いとは言えません。したがって、
LD_PAYMENT_DATE (支払日)
や
LD_POSTING_DATE (転記日)
などのように、より具体的な名称とするのがベターです。
こうすることで、同じ日付を格納する変数でも、別々のものとして扱うことが可能になるのです。
抽象度が高い命名の罠
もし、日付を格納する変数を「LD_DATE」と命名したらどうなるでしょうか？
もう、お分かりですよね。「LD_DATE」に加えて、「LD_DATE2」などよくわからない変数が乱立していく悲劇が生まれてしまうのです。
「LD_DATE2」が生まれた時点で、「LD_DATE」の意味もよくわからないものになるので、最初からできるだけ具体的な命名を付けるようにしておくことが重要なのです。
④名称をむやみに短縮しない
※これについては、賛否両論あるかもしれません。
先ほど、「変数名はできるだけ具体的にする」と説明しましたが、変数名は具体的にすればするほど名称が長くなっていく傾向にあります。
LD_DATE (日付)
↓どんな日付？
LD_PAYMENT_DATE (支払日)
↓何の支払日？
LD_SALARY_PAYMENT_DATE (給料日)
・・・
長ければ長いほど、もちろんわかりやすくなるのですが、言語によっては変数の長さに指定があったり、人によっては長い名称を嫌ったりするため、変数の名称を短縮する場合があります。
LD_SALARY_PAYMENT_DATE (給料日)
を、
LD_SLRPAYMT_DATE (給料日)
などと短くしたりすることがあります。
仮に「AVERAGE」を「AVG」などのように一般的に使いまわされている名称とするのは許容範囲でしょう。
ただ「LD_SALARY_PAYMENT_DATE」を「LD_SLRPAYMT_DATE」としてしまうのは、可読性が著しく低下してしまうため推奨しません。
「LD_SLRPAYMT_DATE」とコーディングされていても、何の変数が誰もわかりませんよね。わからなくなるのであれば、いっそのこと「LD_SP_DATE」ぐらいまで短縮したほうがすっきりしていてよいのではないか、とも思われます。
許容される範囲の長さであれば、変数名は「むやみに短縮しない」方が可読性が向上します。
長すぎる変数名の注意点
一方で、長すぎる変数名にも注意が必要です。
１番はコーディングミスです。長ければ長いほど、プログラマーの単純タイプミスが多くなる傾向にあります。（そうならないためには、できるだけコピペする！）
LD_DATE よりも LD_SALARY_PAYMENT_DATE のほうがタイプミスが多く発生します。