コーディング規約

ハンガリアン記法|悪態のプログラマ経由の、間違ったコードは間違って見えるようにする - The Joel on Software Translation Project。今まで誤解していた、ハンガリアン記法についてです。


世間一般で言われているハンガリアン記法にも、以下の二つの種類があるそうです。

  1. システムハンガリアン
  2. アプリケーションハンガリアン

型の情報(例えば、double word型を意味するdwFoo)のみを示唆するのが前者で、アプリケーション的な意味(例えば、危険な~unSafe~を意味するusBar)を表現するのが後者であるとの説明があります。ま、詳しいことは、上記の元ネタをたどってくださいな。



で、ちょっとしたアプリケーションハンガリアン記法なら、今携わっているR/3のプロジェクトでも取り入れてられています。例えば、ABAPでのテーブル型*1は、以下の三つの記法がプロジェクト内コーディング規約として規定されています。

DATA:
  ITAB_FOO TYPE TABLE OF FOO, " FOO型の入力用テーブル
  TTAB_BAR TYPE TABLE OF BAR, " BAR型の編集用テーブル
  TTAB_BAZ TYPE TABLE OF BAZ. " BAZ型の出力用テーブル

ま、これくらいの情報でもないよりかはあった方が(特に他人のプログラムを)理解しやすいのですが、この記法がものすごく有用かというと微妙なところです。というのも、文法の特性上ABAPは一時変数が多くなりがち*2なので、一時編集用テーブルを意味する「TTAB_***」だらけになってしまって情報としての価値が薄くなるのです。


じゃあ、どのようなものにアプリケーションハンガリアン記法を取り入れたらよいのでしょうか?型的には同じ型で表現できるけども、意味上似て非なるものは異なる扱いをした方がよいでしょう。ですが、R/3ではデータエレメントとして、JavaやCといった一般的なプログラミング言語より型を細かく制御できます。


アプリケーションハンガリアンはコンパイラでは検出されないけれども意味的に異なるものを(人間が見て)検出するのに役立つのです。しかし、そもそもの話、コンパイラに検出させることができるものはそうした方が、安全で手間がかからないのですよね。そういう論点からいくと、(R/3に限っては)アプリケーションハンガリアンが多すぎるということは(データエレメントレベルで適切な型分けができていないという意味で)逆に不吉な匂いの表れなのかもしれません。



何か、いろいろ考えてたらこんな時間になってました…。書いてる途中で、自分でダメ出しをした挙句に没記事にした内容もありましたし。


ブログも書けば書くほど、短い時間でよりよい内容が書けるようになるとどこかの誰かが熱弁してたような気がするので、もっとひたすら書く練習をしないとですね♪

*1:簡単に言うと、Javaでの配列のようなもの。厳密には結構違いますが…

*2:この辺のところも、一度考察してエントリにしたいな…