メニュー
Infomation
■お知らせ
[スパム対策]コメントにURLを含めると自動的に削除されます。
■このサイトについて
一応残していますが、全時代の遺物。全ての情報は古く役に立ちません 連絡先:メールアドレス
■日記更新情報
RSSRSS|RSS(本文のみ)|lirs
実験&リサーチ
巡回先
製作環境
 

 



2004|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|11|12|
2011|01|
2014|05|08|
2017|07|
2018|03|
2020|08|10|
2021|11|

2009年05月15日(Friday) [長年日記]

_ [日記][コンピュータ] ハンガリアン記法(アプリケーションハンガリアン)を使おう

いまだに、というべきなのかどうか分りませんが、プライベートでも仕事でもよく使う言語はC言語とC++です。

PGというわけではないので道具として使うだけで専門家ではありません。


他にまぁ扱える、程度で知っている言語というとPerl、ruby、Java、ActionScript、、あれ意外と知らないなぁ、まぁいいか。


プログラミング言語の用途としては色々あるんですが、最初に入ったのがMS Windowsだったせいもあってなんとなくハンガリアン記法っぽく書く癖がついてしまっています。

しかもみんなに嫌われるシステムハンガリアンです。

例えば整数型の変数の頭にはiとかnとか付けるというアレです。

Microsoftは少し前までこれを使っていて、例えば時刻を表すSYSTEMTIME構造体は以下のように定義されています。


typedef struct _SYSTEMTIME {

 WORD wYear;

 WORD wMonth;

 WORD wDayOfWeek;

 WORD wDay;

 WORD wHour;

 WORD wMinute;

 WORD wSecond;

 WORD wMilliseconds;

} SYSTEMTIME;


WORD型の変数だから頭に全部wが付けられています。

でもこれを推奨したいわけじゃありません。

本来C言語などは型付けが言語で定義されているのでそんな事を変数名で区別する必要がないし、後から型を変える時などのメンテナンス性が下がり良くないという批判があります。

見た目もバッチイですしね。


現在ではマイクロソフトも.NET Frameworkになってからはハンガリアン記法の使用を禁止しています。

一般的な名前付け規則 【MSDN】

>ハンガリー表記法は使用しないでください。


だからハンガリアン記法は使うの止めましょう・・・・ってそうじゃありません。



ハンガリー記法はマイクロソフトの技術者、チャールズ・シモニイが考案し彼がハンガリー人だったのでこんな名前で呼ばれるようになりました。

この人はWordなどの開発に携わった人で優れた実績を上げました。


彼が考えたハンガリー記法の本来意図は変数の種類・用途を示すことであって、実は型を示すことではありませんでした。

種類というのの例をあげると、座業系などがあげられます。


仮にテレビのようにピクセル比が1:1でないディプレイがあったとします。

更にスケーリングも違うとしましょう。

1024×768で出力した映像が1920×1080のパネルに表示されるとかですね。

前者を内部座標系、後者を表示座標系と呼ぶことにすると、出力座業系のX座標と表示座標系のX座標みたいなものは全く無関係の数値で直接足したり引いたりしてはいけない数値だという事になります。


しかし、人間うっかりミスをします。

直接代入してはいけないはずの表示座標系の数値を出力座業系の変数に代入してしまったりするというミスが発生するということです。


int local_pos = 100; //表示位置(内部座標系)

int display_pos = 200; //ディスプレイの表示位置(表示座標系)

int scraoll = 10; //スクロール量(内部座標系)

...色々な処理...

localpos += scraoll;

...色々な処理...

display += scraoll; //おかしい


いい加減な例ですが、おかしな部分があります。

「スクロール量」というのが内部座標でのものなのか表示座標系でのものなのかよくわからなくなってしまっています。

この場合、どちらの変数も同じ型、例えばintで宣言されていたとするとコンパイラは何のエラーも出しません。

人間がその行だけを見ても間違いかどうか分りません。


そこでハンガリアン記法の出番です。

上の例では例えば以下のようにします。


int iLocalPos = 100; //表示位置(内部座標系)

int oDisplayPos = 200; //ディスプレイの表示位置(表示座標系)

int iScroll = 10; //スクロール量(内部座標系)

...色々な処理...

iLocalPos += iScroll;

...色々な処理...

oDisplayPos += LocalposToScreenPos(iScroll);


内部座標系の変数にはiを表示座標系の変数にはoを頭に付けるというルールにしました。

もし、間違えて iLocalPos += oScroll; みたいな事を書いてしまったとしてもその行だけを見れば間違っていることが分ります。

座標系を混ぜてしまっているからです。

LocalposToScreenPos(int val)という関数もoLocalposToScreenPos(int iVal)なんてすれば更に明快かもしれません。


oDisplayPos += oLocalposToScreenPos(iScroll);


これが本来チャールズ・シモニイが意図したハンガリアン記法でした。

同じ型でも混同してはいけない変数の意味(種類)を変数名に与えるというアイデアです。

これなら誰が見ても変数の意味が明確に分ります。

現在ではアプリケーションハンガリアンと呼ばれたりします。


これを知った時はちょっと衝撃でしたね。

実際最初にプログラミングを始めた頃はこの手のミスで痛めにあっていましたから。

ハンガリア人すげー。


大変すばらしいアイデアなのですが、彼はひとつミスをしました。

変数の意味を "type" という言葉を用いて書いて説明してしまったそうなのです。

これが変数の"型"と混同されやがてはハンガリアン記法=システムハンガリアンという誤解が生まれたそうなのです。

しかもマイクロソフト自身もそれを使ってしまったためこの概念は広まってしまいました。



といわけです。(・・・何がだろう)


要するに、アプリケーションハンガリアンはとても有用だということです。

僕はシステムハンガリアンとアプリケーションハンガリアン混ぜ混ぜですが、システムハンガリアンはC言語でWindowsのAPIを直接いじるプロジェクトのみで使用するようにしています。

APIを直接呼ぶことが多いので自然とMicrosoftの型に合わせてしまうんです(半分言い訳)


システムハンガリアンはC言語以外では使うことは少ないと思いますし、C言語でもあまり意味がないというのは前述のとおりです。

でもアプリケーションハンガリアンは違います。

場合にもよりますが、ものすごく有用です。

JavaでもPerlでも。

いくつもの変数の"意味"があるプログラムをされるアナタ。

ハンガリアン記法はいかがでしょうか。



上記のことは以下に詳しく書かれています。

Making Wrong Code Look Wrong 【Joel Spolsky】

間違ったコードは間違って見えるようにする(和訳されたもの)

本日のコメント(全1件) [コメントを投稿]
§ LiedgeTit (2012年01月18日(Wednesday) 02:07)

is tramadol stronger than percosets tramadol in a pee test <a href=>tramadol high the same as percocet</a> <br>does tramadol contain codeine prescription tramadol <a href=>tramadol replacements</a> <br>tramadol dog dose tramadol opioid <a href=>tramadol best price</a> <br>tramadol controlled drugs tramadol overnight price per 300 <a href=>tramadol pill with 377 on it</a>


最近のコメント

364,000 at 2008.06.14
Copyright (c) Suika KNOnline.NET