2007年04月22日(日)

ハンガリアン記法

テーマ:コーディング

変数などの名前を付ける時のコーディングルールに、ハンガリアン記法(ハンガリー記法)と呼ばれるものがある。簡単に言えば、名前の先頭に「型」などを表す文字列(プリフィックス)をつけるというものである。


かつて Microsoft が好んで採用しており、 Visual C/C++ (MFC) を使ったWindows プログラミングの仕事が多かった私の会社では、社内ルールとしても採用されている。



というわけで、私も、ハンガリアン記法で多くのコードを書いてきたのだが、あるとき、Joel Spolsky 氏の「間違ったコードは間違って見えるようにする 」という記事を読んでショックを受けた。


それまで私が書いてきたハンガリアン記法というのは、MFC でやっているように、変数名に「型(type)」を表すプリフィックスを付けるものだった。しかし、それは「システムハンガリアン」と呼ばれ、本来のハンガリアン記法ではなかったのだ。


本来のハンガリアン記法とは、「アプリケーションハンガリアン」と呼ばれ、プログラミング言語の「型」とは無関係に、データの「種類(kind)」を変数名で表現する方法であった(※1)。


アプリケーションハンガリアンを使えば、変数間の互換性(端的に言えば、代入してもよいかどうかということ)が、コードの読者(コードを利用する人、改造する人、デバッグする人、レビューする人、そして、そのコードを書いた人自身)に明確に伝わる。ここでいう互換性とは、文法的なものではなく、意味的なものである。文法的な互換性はコンパイラがチェックしてくれるが、意味的な互換性は人間がチェックするしかない。


つまり、本当に有用なのは、文法的な「型」を明示するシステムハンガリアンではなく、意味的な「種類」を明示するアプリケーションハンガリアンなのである。



今では、Wikipedia にも「アプリケーションハンガリアン」と「システムハンガリアン」の違いが記述されている(※2)。しかし、古参のプログラマは、あらためてハンガリアン記法の意味など調べない人がほとんどだろう。一方で、Microsoft からシステムハンガリアンが消えようとしている時代にあって、新参のプログラマが、ハンガリアン記法について考える機会はどんどん少なくなるだろう。


しかし、そんな時だからこそ、アプリケーションハンガリアンの価値を再考すべきではないだろうか。特に、自前のコーディング規約の作成を考えている人には、是非とも先に紹介した記事は読んでもらいたい。プリフィックス方式を採用するかどうかは別にしても、少なくとも、意味的な種類(kind)を明確にする、という考え方は取り入れるべきだろう(※3)。







※1
もちろん、アプリケーションハンガリアンを使わない場合でも、変数名はデータの意味的な「種類(kind)」を表すようにすべきだ。しかし、それをプログラマ個人に任せてしまうと、不統一になってしまって意味がない。ルール化するということが大切なのだ。


※2
2007/4/22 現在。Wikipedia の項目名は「ハンガリー記法 」となっているが、「ハンガリアン記法」への改名が提案されている。


※3
システムハンガリアンのルールを作るのが簡単だが、アプリケーションハンガリアンのルールを作るのは難しい。しかし、Joel Spolsky 氏の記事にある「本当の解決法」はそのまま使えるし、他のルールを作る上での参考にもなる。また、類似したデータを取り違えてバグになった経験を思い出せば、いくつか思いつくのではないだろうか(例えば、「YYYYMMDD」と「YYMMDD」、「ゼロ埋めしているデータ」と「ゼロ埋めしていないデータ」、「枝番つきコード」と「枝番なしコード」、「協定世界時」と「日本標準時」、文字コード違いの文字列・・・)。



■関連記事

チームのために自分のスタイルを曲げる覚悟
慣例的コーディングルール
プログラムに操られた男
その名前、紛らわしい!
読者指向プログラミング




Joel on Software
Joel on Software
posted with amazlet on 07.04.22
Joel Spolsky 青木 靖
オーム社 (2005/12)
売り上げランキング: 1815
おすすめ度の平均: 4.5
5 実際に現場で使わせてもらってます
3 優秀なソフトウェア開発者の日々の徒然
3 プログラミングチームを率いるときに


C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス
Herb Sutter Andrei Alexandrescu 浜田 真理 浜田 光之
ピアソンエデュケーション (2005/10)
売り上げランキング: 37199
おすすめ度の平均: 5.0
5 上級者には心得集、中級者にはポインタとして
5 この二人以上にC++について語れますか?
5 文法だけでは分からない、C++の書き方

AD
いいね!した人  |  コメント(7)  |  リブログ(0)

argvさんの読者になろう

ブログの更新情報が受け取れて、アクセスが簡単になります

コメント

[コメントをする]

7 ■RE: 初めまして

etsuha さん、こんにちは。

アプリケーションハンガリアンという優れた考え方も、システムハンガリアンのように誤って普及してしまうと意味がないですね。

ルールを作って活用するときは、その背景にある意図をしっかり伝えることが大切と感じました。

6 ■初めまして

 テスト運用などについて調べているうちのこちらにお邪魔し、深く感銘を受けたのでコメントさせて頂きました。

 わたしは組み込み系のソフトウェア開発に携わっているのですが、会社自体のノウハウがまだ十分で無い為に何かもっと品質を向上させたり、役に立つ開発現場の運用法がないかを調べていました。

 そして本文中で紹介されている文献を読んだのですが、これは本当に驚きの一言に尽きます。

 常々、デバッグ作業を複数人で行う場合(長期間に渡る自分自身も含めて)可読性がプロジェクトに浸透しているかどうかが鍵になると考えていました。
 可読性はよくあるコーディングルールや、構造体やポインタ、またファイル間の構成にまで及び一貫して開発スタイルとして体系化出来そうであると感じながら苦戦していたのですが、アプリケーションハンガリアン記法が目指す目的とその効果、実現手法に感服しましたね。

引用:
本当に信頼性のあるコードを書く方法は、人の典型的な弱さを考慮に入れる~

 まさにその通りですね。
 大事なのはトラブルの元を無くすのに規則でがんじ絡めにする事ではなく、起こりうるトラブルを想定した一手を打っておく事だと思いました。

 長文、失礼しました。

5 ■無題

ブログ拝見させてもらいました!

4 ■RE: はじめまして

う~さん、こんにちは。

>自分ならsText/usTextと書くよりもはっきりとsafeText/unsafeTextと書く方を選びます。

プリフィックスの長さが違うだけで、本質はおなじですよね。私も基本的には長いほうが分かりやすくていいかと思います。しかし、「長いとタイピング効率が悪い」という意見も分かります。

結局のところ、使用頻度やプログラマの人数なども考慮して、適切なルール化ができればいいかと思います。

3 ■はじめまして

ハンガリアン記法にシステムハンガリアンとアプリケーションハンガリアンの2種類があるとは知りませんでした。
アプリケーションハンガリアンの考え方はとてもいいと思います。
でも、やっぱりハンガリアン記法は苦手ですね…
自分ならsText/usTextと書くよりもはっきりとsafeText/unsafeTextと書く方を選びます。
sText/usTextだとsignedText/unsignedTextと誤解しそうです(汗)

2 ■RE: ブックストア参考にさせていただきました☆

Lico さん、こんにちは。
ぜんぜんメンテしていなくて、お恥ずかしい限りです。

1 ■ブックストア参考にさせていただきました☆

大変お世話になっております。System ArchitectのLicoです。
argvさんのオリジナルブックストアがうらやましくて、
僕も自分のブックストアを作ってみました。
もしよろしければ、また遊びにいらしてください。
それでは、ブログ作成頑張っていきましょう。

PS. 記事とは直接関係ないコメントですみません(^^;

コメント投稿

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。