特にアプリケーションハンガリアンについて。
アプリケーションハンガリアン
ハンガリアン記法は変数名に型を表す接頭辞（プレフィクス）を付けて意味を分かりやすくするもの。
でも変数宣言と重複するような型はただの重複。変数名と型の不整合を招く悪例。
boolean型にbとか、double型にdとか。
こういったプログラミング言語が用意している型をそのまま接頭辞にしちゃってるのをシステムハンガリアンと呼んで、本来のハンガリアン記法であるアプリケーションハンガリアンと区別しているみたい。
「アプリケーション固有の接頭辞を考える」ということで「アプリケーションハンガリアン」なんだろうか。
ハンガリアン記法にはアサーションと同じ効用があると思う。
シンボルの意味を分かりやすくするだけでなく、型による検証をよりよくできる。プログラミング言語が用意しているものよりも詳細な型を定義するのと一緒。
例
例えば…
- 文字列ならなんでも入れて良い変数に"s"を付ける。
- 文字列のうち、","を含まない変数には"snc"を付ける。
というルールを設けたとき、snc変数に対してなら可能だけどs変数には不可能という処理が考えられる。
それはCSVフォーマットに変換できること。
つまり、CSVにして出力するような処理に渡せるのはsnc変数ということに。ここでs変数を渡してしまうとバグの種になる。
こうしておけば「CSV出力処理に渡す文字列に","が含まれているときどうしているんだろう？」という疑問は無くなるし、CSV出力処理内で","削除をしていればそれは無駄なコードだと分かる。
CSV出力処理をsnc型データの生成処理と","付与処理に分けたり、snc型データの生成方法を","削除処理と置き換え処理の2つに分けたりするのは構造化プログラミングの一環にもなる。
無論、s変数からCSVを生成する処理も作れるが、","を削除した時点で「それって処理中にsnc変数を作ってるんじゃね？」ってわけで、やはりCSV変換できるのはsnc変数ということになる。
CSV変換処理を作ったとしても、引数は文字列型ということしか定義できない。コンパイラーは文字列型であること以上は関知しない。
ただ文字列というだけでは正しいCSVフォーマットになるとは限らない。組み込み済みの型は曖昧で実用に耐えないんだ。
通常なら開発者が曖昧な型しか解さないコンパイラー様に合わせて、どんな文字列でも渡せるCSV変換処理を作るところ。
でも、コメントで渡せる引数はsnc変数だと明記しておけば余計なコードも頭も神経も使わずに適切なデータを選べる。しかもコンパイル前。コーディングの段階で。
