生き様086. ハンガリアン記法とオブジェクト指向

エンジニアリング | 学習

» 2021/04/01

YouTubeチャンネルリニューアル！

本日、4月1日付で僕のYouTubeチャンネルがリニューアルされました。
まず、チャンネル名が「白栁隆司のコレざまTVチャンネル」になります。

そして、２つの新しいコンテンツが動き出します。

新コンテンツ第一弾は、本日18:30に公開される「#コレざまTVラジオ」です。
毎回、ゲストをお呼びして、フリートークをしながら、その人の生き様に迫っていく音声コンテンツです。
このコラムでは文章で僕の生き様を公開しているわけですが、このコンテンツでは音声で僕以外の人の生き様を伝えたいと考えています。
こちらは、毎月1日18:30に新作が公開される予定です。
記念すべき第一回のゲストは、エンジニアライフでお馴染み 勝ち逃げ先生さんです。
プレミア公開を使用しますので、白栁もチャット欄に居る予定です。一緒に見ましょう！

新コンテンツ第二弾は、明日21:15から開始する「#Switchでおうちフィットネス」です。
こちらは僕の生き様というか、醜態を晒す企画です。
昨今の引き篭もり生活で鈍った身体を動かして、運動不足を解消していきます。
一人でコツコツやると続かないので、いっそのこと公開して配信にしよう、と。
毎週月・金曜日21:15から1時間程がんばります。
白栁がサボらない様に、叱咤激励を飛ばしに来て下さい。
なお、ゲーム画面のみで実写が登場する予定はありません。

既存コンテンツの「#ほぼ日ITエンジニアニュース」や「LT動画」「商品レビュー」等も、順次新作をアップしていく予定です。
こちらも合わせて宜しくお願い致します。

毎月第一週は技術ネタ回

技術力ボロボロな現役エンジニアが、精一杯の技術的知識を披露するお時間です。
反響が良いのか悪いのか。需要があるのかないのかわかりません。
是非、コメントやこの記事をツイートして、ご意見やご感想を下さい。

今回のテーマは、「ハンガリアン記法」です。
僕自身はこの「ハンガリアン記法」という呼び方が好きではないのですが…。
一般的にこういう呼び方で広がっているので、仕方なく習うこととします。
他に適切な呼び方が見当たらないのも理由ですが…。

闇の多いハンガリアン記法

ハンガリアン記法は、2000年代前半のシステム開発業界で大流行しました。
この当時、開発環境のシェアトップだったVisualStudioを開発・提供していたMicrosoftの公式ドキュメントに記載されていたコードも、多くがハンガリアン記法で書かれています。
当然のごとく、この当時のSESなITエンジニアは、漏れなく現場のコーディング規約としてハンガリアン記法を叩き込まれております。
僕は今でも、VBAを書く時はこの時の手癖でハンガリアン記法な命名をしていまいます。

未だに一部界隈で需要が高いDirectX9系のライブラリドキュメントや、
たまにコレを使わないとにっちもさっちもいかなくなる、Win32.DLL系のドキュメント。
これらから、この当時の風潮を読み取ることができます。

しかし、この当時の世に広まっていたハンガリアン記法が、生産性に何らかの寄与をしたか？というと…残念ながら首を傾げずにはいられません。
詳細は後ほど説明しますが、仕様変更等で余計なコストが発生していた様に感じます。
ウォーターフォールなのに設計技術がさほど高くなく、頻繁に設計差し戻し＆修正が発生していた、当時のSESな開発環境において、これは歓迎できるものではありません。
今ほどIDEが良かったわけでもありませんので、全体の一括置換はできません。
ヒーコラ言いながら、コンパイルエラーを頼りに潰していた記憶があります。

これ以外にも数多くの【闇】な部分があるのですが、それは後々に。
小出しにしていきたいと思います。

ハンガリアン記法の歴史（ざっくり）

前半はWikipediaの丸写しになります。 90年代初頭。チャールズ・シモニーが考案し、初期のExcelやWordの開発に使われたそうです。
その中で有用性が確認されて、その後のMS社内での開発に広く使われた様です。

当時のMS社のドキュメントに記載されたサンプルソースにも、ハンガリアン記法が使われていました。
恐らく、そこからコーディング規約の考え方が広まるにつれて、日本のシステム開発の現場でも広まったのでしょう。
僕がハンガリアン記法に触れたのは、2001年か02年ぐらいです。
流行としては末期ですね。

その後、.NETへ移行した頃には、ハンガリアン記法が利用されなくなりました。
この頃には、MS社内でハンガリアン記法の有用性が否定されたからでしょう。
2010年に入るぐらいまでは、日本のSESの現場で生き残っていたのを観測しています。

ハンガリアン記法とは

「ハンガリアン記法」という命名には、提唱者のチャールズ・シモニーが「ハンガリー出身だったから」という由来があるそうです。

原文とそれに対する、日本語訳がされたサイトがあります。
詳しくは上記のサイトに譲ります。

僕が経験したのはVBでの開発現場でしたから、上記サイトに書かれている様なルールは厳密に適用されていませんでした。 僕が経験した「SESでのVB言語でのハンガリアン記法」は、およそ以下のルールで変数を命名していました。
［］の括弧で括られた範囲は、文字の属性を表します。
()の括弧で括られた数字は、その属性を表現する文字数を表します。

[スコープ範囲(1)] [データ型(3)] [変数名(～8程度?)]

少し例を出しましょう。

・クラス内でプライベートなスコープを持つint型の距離（km） 　→ pintKyori
・引数として渡された文字列型のメッセージ 　→ astrMsg
・グローバル（プロジェクト内からどこでも参照可能）なfloat型の税率 　→ gfltTax

これと関係あるのかは謎ですが、当時変数名を省略することが善しとされていました。
これも幾つか例を上げましょう。

・件数 Count → Cnt
・メッセージ Message → Msg
・ボタンコントロール Button → Btn
・画像データ Picture → Pic

この省略形がコードの可読性を下げていたという【闇】があります。
厳密にはハンガリアン記法の闇ではないのかもしれません。
ただ、全く無関係でも無いように思えるのです。型を3文字で表現する辺りに…。

誤ったハンガリアン記法

さて、ここまで長々と語ってきたのは、実は「誤ったハンガリアン記法」です。
俗に「システムハンガリアン」とも呼ばれます。
実は、今回取り上げる最大の【闇】はここにあります。

「ハンガリアン記法」とは、本来は「データの属性」を変数名に埋め込むことで、演算時の不正な処理を回避しよう、というものでした。
これについては、後ほど詳しく説明します。

これが不幸なことに「データの型」と誤解をされてしまいました。
そこから生まれた「システムハンガリアン」が世に広まってしまったのです。

「システムハンガリアン」では、設計変更により型が変わった場合に、該当するすべての変数を修正する必要があります。
引数として関数に渡されたり、クラス内部で使用したりされていれば、その全てが修正対象になります。
幾度となく経験していますが、その全てを手作業で修正するのは苦行です。
かといって、テキストエディタでの一括置換も怖さがあります。
多くの場合で「目についたとこだけ」と中途半端に修正されて放置されていました。

こういう現象が起こることを、2020年代の視点から眺めると、容易に間違っていると気付けます。
ですが残念ながら当時はCOBOL等、変数名の文字数上限が厳しかった言語を経験している人達がメンターとして活躍していた時代です。
これらを、コンピューターの性能が上がり、自由にコードが書けるようになった時代の過渡期的な出来事と読み取ることもできるでしょう。

どちらにせよ、2020年代の現代においては「ハンガリアン記法は悪である」という評価が一般的です。
その多くは誤用である「システムハンガリアン」への印象なのですが。

本当のハンガリアン記法

シモニーが唱えた「本当のハンガリアン記法」にも俗称があります。
「アプリケーションハンガリアン」です。

これは前述の通り、「データの属性」を変数名に埋め込みます。
これにより「演算の際に間違っているコードを間違って見えるようにする」ことを目的としています。

例えば、ある生産管理システムを例に考えてみましょう。
システムに内で「ロット数」と「ロット内のアイテム数」という2つの数量をいます。

・生産時間を計算する場合はロット数を利用する
　 → LotCount x Time
・必要な材料を計算する場合はロット内のアイテム数を利用する
　 → LotItemCount * Zairyo

僕の英語力の低さ故に、とても不適切な名前になっていることをご容赦下さい。
他にも、絶対座標と相対座標を組みわせて使う様なケースで、それぞれを判別しやすくしたり。
国際的に複数の単位が使われるものに対して、変数名にその単位を入れることで、計算で混同することを防いだり等、使われ方は色々あります。

ハンガリアン記法とオブジェクト指向の親和性

さて、ここにたどり着くまでにかなり文字を浪費した気がします。
今までのことが正しく伝わっているのか、自分の説明力に疑問を感じていますが。
正直、ここだけが伝われば良いと思っています。

僕は、この「本当のハンガリアン記法」が、現代的なオブジェクト指向に通じるものがあると考えています。
それは「ValueObject(値オブジェクト)」です。

値オブジェクトは「データの属性」をそのまま「オブジェクトの型」とすることで、使われる場所のミスを、コンパイルエラーとして検知する技法です。
これは「演算の際に間違っているコードを間違って見えるようにする」を、コンパイラに任せている、ということに他なりません。

だからといって、現代にハンガリアン記法を持ってくる必要性は無いでしょう。
既に型で表現しているものを、わざわざ変数名でも表現する必要はないからです。

今使っている技術は、ある日突然ぽっと生まれたのではありません。
先人が工夫を凝らし、寄り道や挫折を経た上でたどり着いたものなのです。
どうかそのことを覚えていて欲しいな、と願うのです。

直接繋がっている様には見えない、変数名と型にこんな繋がりがあったわけです。
こういう事柄から、技術って面白いなと、改めて感じました。

おまけ：システムハンガリアンの功績

僕がシステムハンガリアンの功績だと思っている事が１つあります。

それは「プリフィックス(接頭詞)」「サフィックス(接尾詞)」の概念を日本のシステム開発の現場に広めてくれたことです。

メソッドの引数とインスタンスフィールドの名前が一致した時に、「_(アンダースコア)」や、予め決められたプリフィックスを付けることで区別を容易にすることもあります。

【闇】ばかりが取り上げられるシステムハンガリアンですが、功績と呼べることがある、ということでした。

以上！

---

主催イベント宣伝

2021年4月23日（金）に再びオンラインイベントを主催致します。
その名も『【超ショート】90秒LT会【2021Spring】』です。

春といえば出会いと別れの季節。
何かへの出会いへの期待や、惜しみながら別れたものへの思いを。
もしくは、オンラインイベント登壇の試しに、90秒でお話してみませんか？
どんなイベントになるか見てみたい、という方も参加歓迎！！
他人の目標や登壇を聞くだけでも、勉強になりますよ！

現在、登壇参加者・視聴参加者を募集しております。 上記リンクのConnpassページから、参加登録をお願いします。

また、このイベントは3ヶ月ごとの開催を予定しています。
今回ご都合が悪い方は、是非次回、7月のイベントへの参加をご検討下さい。
宜しくお願い致します。

---

ミニコーナー：こちらヤマネコシステム技術部三課！

ここは日本のどこかにあるかもしれない「ヤマネコシステム」社。
そこはかとなく、ブラックの香りがするこの会社の日常を、少し覗いてみましょう。

エイプリルフール

（朝礼中）
ゴリタ主任	「今日から社内のコーディングルールが変わることになりました」
	「部内に一斉メールでドキュメントの場所を通知しています。資料をよく読んで、今日から適用して下さい」
ヒノモト	「げっ。これって…」
ホンドくん	「あー、ちょっと懐かしいね」
オナガさん	「え？そうなんですか。ちょっとめんどくさそうだなって思いますけど」
ホンドくん	「これって、システムハンガリアン記法だよ。20年ぐらい前に流行ったやつ」
ヒノモト	「ウチじゃぁ、10年ぐらい前まで現役だったけど…」
	「ゴリタ主任が主任になって駆逐したはず…」
（ざわつく課内）
ゴリタ主任	「…というエイプリルフールネタでした」
	「以上、各自今まで通り業務を続けて下さい」

（つづく）

---

チャンネル名は変わりましたが、こちらはデザインのマイナーチェンジ程度です。
ITエンジニアの視点で、時事ニュースを5分間で紹介する動画を平日毎日公開してます。
「日々の生活の中にエンジニアリングがある」からこそ、
身近な時事ニュースから学ぶことが重要です。

#ほぼ日ITエンジニアニュース

ハンガリアン記法も、一太郎も、結局は道具です。
どういう目的でその道具を使っていくのか。
その意志が伴わないのが「道具に使われている状態」なのだと考えています。