過去のテーブルトーク

2002/04/02 ハンガリ記法の話２
続きです。最後の反論はプログラミングの変更に関する問題です。例えば変数の型が変化した場合、全ての変数名を変更する必要があります。昨日の例ですと、sTotalCountがshort型整数からlong型整数に変わった場合、プログラム中のsTotalCountを全てlTotalCountに変える必要がでてきます。非ハンガリ記法であれば、このような必要はありません。これは一見すると正常な反論のように見えますが、実は設計段階で変数の上限は考えておくべき事柄であり、プログラミング後に慌ててshort型からlong型に変えるような真似をするのでは本末転倒です（とはいえＯＳの変化によって、もともとの型のサイズが変化することは有り得るため、設計が合っているのに適合しなくなるという悲劇も存在しないわけではない）。それでは、今度はハンガリ記法の利点を見ていきましょう。そのためには、そもそもハンガリ記法がどうして誕生することになったかを考える必要があります。発端は何度も言っていますが、ＧＵＩです。ＣＵＩベースのプログラミングにおいてはコード量は大きくなく、一人でしこしこと組んでいればよかったのですが、ＧＵＩベースになるとコード量が一気に数十倍に膨れ上がることになりました。そのため、オブジェクト指向言語が誕生するまでの間は構造化言語で対処する必要があったのです。構造化言語でＧＵＩを処理するためには一人でプログラミングするのは至難の技です。そこで複数人で一つのプログラムを仕上げるために設計と言うものが極めて重要視されるようになりました。また、本来構造化設計においては関数はコードが５０行（場所によっては１００行）を越えたら関数分けするというのが基本だったのですが、こうなると細かく関数で切りまくらなければならなくなり、ちょっとしたＧＵＩプログラムで１００個の関数を使用するなどというとんでもない事態にも為りました。これではデバッグも何もできませんから、軒並み一つの関数が長いコード量を持つことになります。続きます。前　後

Topへ