ハンガリアン記法 [part1]

ハンガリアン記法ってどうよ　(使ってる人・使ってない人)

さぁ意見を
↓

結論
http://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B

まぁ語れよ

>>2 を読め。そこに全てが語ってある。

これが全て正とも言い切れまい >>4

それより語ろうぜポーランド記法を

（　＾ω＾）断る>>6

逆ポーランド記法だろ

言い切れる。

終了

結局のところ（特に日本では）、「MSが牽引しているからイヤイヤ」という感情面から入ってるバカが多いような気がするんだけど。
個人的にはどっちでもいいと思うけど、むやみやたらに毛嫌いする変な人が多い。
もう見ただけで「うわーもうやってらんね。俺様のスーパー技術者人生としてのプライドに関わることだから。絶対こんなのツカワネ」。

ハンガリアン記法はともかく、
youcanfly()やyou_can_fly()より、YouCanFly()の方が読みやすくないかな？
俺が日本人だから？ 英語に馴れてる人なら前者の方が読みやすくなるんだろうか（外人は前者の人が多いと思う）。

>>9は、反ハンガリアン記法信者か

俺も>>10同様どちらでも構わないと思う。強いて言うならばアプリケーションハンガリアン記法は、採用すべき。
>>2のURLにも書いてあるが・・・

>>10
> youcanfly()やyou_can_fly()より、YouCanFly()の方が読みやすくないかな？
> 俺が日本人だから？ 英語に馴れてる人なら前者の方が読みやすくなるんだろうか（外人は前者の人が多いと思う）。

言語ごとにマジョリティが異なるな

>>10
読みやすい読みやすくないじゃなくてなんであるかによって使い分ける。
例として、

大文字で初めてCamelCase → クラス名
大文字だけを使う → 定数
小文字で初めてcamelCase → メソッド名
全部小文字で単語間に_を入れる → 変数名

みたいな感じ(あくまで一例、他のルールももちろんあり得る)。
ハンガリアンではないけど見た目で何かすぐわかるので、
ハンガリアンの考え方は取り入れてる感じ。

>>11
ちがうだろ、>>9のはjoelで全て語り尽くされてるって話だろ？

俺もアプリケーションハンガリアンは推奨派だし使う。
ちなみにシステムハンガリアンは有害。

hwndHogeとかhbrHogeとかって名前使うんだ俺。

これがC#でIntPtr型ならきっとアプリケーションハンガリアンだろう。
しかし、C++でHWND型とHBRUSH型を使っていれば、
とってもシステムハンガリアンに思えないか？
そう思いつつ、今日もC++でそんな変数名を付けている。

それは別にアプリケーションハンガリアンだと思うぜ。

15はアプリケーションハンガリアンの意味を理解しているのか?

>>14 システムハンガリアンが全ての場合で有害だとも言い切れなくね？
現在、多くのJavaプログラマがString型オブジェクトならば「str○○○」のように使用しているし、全てが有害って判断は遺憾に思うぞ。

> 現在、多くのJavaプログラマがString型オブジェクトならば「str○○○」のように使用しているし、

…そうか？

そうじゃない？

つかってないだろ
Javaで言ったらboolean型がis○○だったりhas○○だったりするくらいじゃね？

文字列に str つけるのはアプリケーションハンガリアンじゃないのか？

もやもやした範囲だな＜str

SQLクエリー文字列
iniファイル文字列
GUI表示文字列
Web表示文字列
これを全部同じstrにくくるとな？

>>18
疑問にも思わず使ってる連中がいたとしたら、
そいつら全員莫迦なんだから遺憾も糞も。

モンゴリアン記法とか新しい呼び名を付けるべきなんじゃないか

馬鹿なスレだな

そりゃ part1 の時点でもう

>>22
アプリケーションハンガリアンで付けるプレフィクスは型情報じゃない。

>>18
javaでそれは見たことないな。VB6.0時代なら腐るほど見たが。

俺もJavaで>>18みたいのは見た事無いな。

配列とかリストの変数名を複数形にするのも一種のハンガリアンかな？

単複同形の単語とかどうすんの

複数形はハンガリアンってわけでもないような
foreach (var user in users) {
  ……
}

foreach (var users in user) { 
  …… 
}
胡散ｸｻｰ

聞いてる暇があったらJoelのとこなりWikipediaなり見てくりゃいいのにな。

>>18
strなんちゃらは有害

おれはstrに錦野関係の情報しか入れないようにしているから、有害といわれると心外だ。

そりゃ star だ。

ウチの職場では実際スターと発音するのが居る
スター派、ストラ派、エスティーアール派などなど
お前等は何て読むよ？

ストリング

ストレングス

ストリップ

ストリングだな
bufとかはバフとか言うけどこれだけは何故か略さない
LPTSTRとかの意味が分からなくて小一時間悩んだせいかもしれん

>>36　ｋｗｓｋ

このスレのスレタイが目に入る度に脳内フィルターがかかって
ジャンガリアン記法に見えてしまうのですがどうしたらいいでしょうか？

>>44
36は、18の言うシステムハンガリアンが全ての場合で
有害だとも言い切れなくないというのに賛成できないだけだと思う。

アプリケーション版画利案ならいいと思うが、最近流行のアノテーションを
使って型（type）チェック以上の種別（kind）チェックができるんじゃないかな？

ダメなコードが変に見えるように、ならアプ版画利案で十分だけど、
実際のところコンパイラが自動チェックすればもっといい。

　@[kind = my.unsafe]
　string read_param(string key);
　
　@[kind = my.safe]
　name = read_param("name");

とか書いて、

　mylanguagecompiler -Wkind my.code

とかで typecheck ならぬ kindcheck が勝手にかかれば版画利案の醜い字面に
耐えることなく同じ効果を享受できる。

強い typedef があればいいんだよな。

いや、type一本とかkind一種類じゃなくて、任意の種別情報を付加して
コードチェックの自動化ができればいいってこと。単なる強いtypedefだと
Pascalになってしまう（長さが違うだけで違う型です！とか）

Javaとかのオブジェクト指向言語なら、何でもStringにぶち込むのはやめて、
適切にクラスを作ればいいだけのような。

クラスの数だけファイルが出来る。

Javaとかでも変数がnullを取りうるか、メソッドがnullを返すかを識別するために、
語尾にNをつけるようにしてる
Nがついてるものはnullチェックしないとダメ、とルール化できる

JavaにはそのうちNonNullアノテーションとか実装されるんだっけ

宣言的例外処理とかアホなことをしてきたJavaなら
NonNullもマジでやっちゃうかもな
煩雑極まりないことになりそうだが

Hungarian Notation : Charles Simonyi
ttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs600/html/hunganotat.asp

ぬるぽ

次スレタイトルはこれで

土旦土旦 ハンガリアン墓場 旦土旦土

このスレが次まで続けばな >>57

あげ

がっ　

型情報が重要なこともしばしばあると思うんだけどなぁ
m_strName
見た瞬間に、String型でメンバー変数なのね。って分かる

他人のプログラムの文中に
Name
って変数が出てきた時って、みんなどうやって情報集めるの？
カーソルあわせて型とかが出るまで待つの？

何の脈絡もなく突然変数名が出てきたりしないでしょ。
だいたいは関数とかクラスの宣言見ればわかるし。

出所不明な変数が突然出現したら、一体どこから来た何に使う変数なのかってのを調べなきゃいけない。
型だけわかったって足しにならないよ。

俺はそれがStringなのかどうかの前に
サニタイズやエスケープされてるのかが気になるよ。

>>61
変数を見ただけで型が分かったとして、それが正しいかを結局は調べる必要がある。

型情報なんざ、コンピュータに検査させれば良い。
メンバ変数かどうかも同様。

まさかメモ帳で開発してるわけじゃないだろ？

そうか
きっと糞ソースばっかり見せられてるから「せめて（システム）ハンガリアンくらい使えよ。（どうせお前じゃアプリケーションハンガリアンなんてできないだろうし）」
って思っちゃうんだな

カツカツの携帯電話プログラムやってると、まだまだハンガリアンにはお世話になる
Javaなのにクラスなんて1つもつくれないし、関数も少なめにしなくちゃいかん

それとハンガリアンにどういう関係があるのかサッパリ理解できんけど。。

>>68
限られたリソース空間にプログラムを詰め込もうとすると
構造としてのわかりやすさを犠牲にすることがある、
それゆえ字面のテクなんかでわかりやすさを確保せざるを得ない、
ってことでしょ。
おれはプログラマじゃないから適当に想像してみたw

このまえOLESTRとLPCSTRとPSTRとLPCWSTRとstd::stringとCStringとchar[]と
std::vector<char>とstd::vector<unsigned char>あたりが混ざったプログラムが出てきたが、
おいらもハンガリアンについて考え直さないといけないな。

ハンガリアンはもう古い。
今はモンゴリアン。



チョップ。

ハンガリアン記法なんてエディタが貧弱だった頃の負の遺産だろ

エディタが強力になってもハンガリアンの代替機能なんてほとんど使わないでしょ。
例えばインテリセンスとかでいちいち型確認してる？
しないね普通。

つまり最初から必要なかったんでしょ。
パラノイア気質の奴が最初から必要もないものを強迫的に必要だと思い込んじゃっただけっぽい。

>>73
お前が孤独プログラムばっかりしてるってだけの話

ハンガリアンに限らず何に対しても、有効に活用できる人・できない人がいるわけで。

それは対パラノイア以外の有用性が認められなかったから廃れた、という事実を
君が認められないだけだね。

>>18
Stringのフィールドでもstr付けるのか？
アクセッサはgetStrhoge()とかになるんだろ？

パラノイア=MS信者

いちにいハンガリアン、にいにいハンガリアン

MSが方針転換して以来、
MS信者は嫌ハンガリアンパラノイアになったから
話が盛り上がらないな。

昔も似たようなスレあったな
俺はシステムハンガリアンも有効だとレスした
IDEによる入力サポートとか、カーソルあわせての型情報とか一切無い環境もあるからな
ってか俺のとこそうだし
と書いても理解してもらえなかった。
多分ここでも理解してもらえないなｗ

理解は出来ないが、同情は出来る。

理解は出来るが、一緒に仕事をしている同僚じゃないんだからわざわざ理解させる必要なくね？

システムハンガリアンなんて確実にいらないでしょ。

↓の人が、本物のハンガリアとはアプリケーションハンガリアンのことで、
こちらは有益だって力説してる。
http://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B

でもどうかね。
確かに一理はあるし、確かに複数の座標系があるときにどの座標系かを区別するような
用途にはある程度適合的かもしれんが、やはり正攻法じゃないと思うな。

>>83
>>2

馬鹿か？
だからアプリケーションハンガリアンの有用性も疑わしい、といってるんだけど

正攻法ってなんだ？
正攻法でなければいけない理由ってなんだ？

にたとえば要するに、ドルと円をおなじintで保持ししてるから(せざるを得ない)
からアプリケーションハンガリアンが必要なのであって、
Currency<Doller>オブジェクトとかCurrency<Yen>オブジェクトを
つくっておけば、「型」システムに組み込まれるので要らない、みたいな話？

通貨ならそこまでしなくてもPriceInYenとかPriceInDollarsってすれば済む。
ynPriceとかdlPriceとかに合理性は見出しにくい。

あるいは、仮想的な概念として「価値」を考えてそれを型にするのも一つの手だね。
Price.InYenとかPrice.InDollarみたいな感じ。
この考え方は上の複数の座標系にも応用できると思う。

>>88
何を言ってるんだお前は？
別にアプリケーションハンガリアンは、頭を小文字にとかそういう話をしてるわけじゃないぞ？
「変数名の生成を、その変数の種類(kind)に基づいて特定のルールづけの元行う」
というのが趣旨だ
お前がPriceInYenとかのほうが見やすいというのなら、そうすればいいだけの話

>>88
それが、アプリケーションハンガリアンなのだが。

仮にそれが正しいのなら（いや間違ってると思うが･･･）
そもそも「アプリケーションハンガリアン」などというカテゴライズには
最初から何の意味もないことになるな。

だってPriceInYenとかPriceInDollarsなんてのはごく普通の何の変哲もない
命名に過ぎないじゃないか

>>91
君がたまたま自然に「アプリケーションハンガリアン」を受け入れていただけの話
知ってか知らずかね

何も考えない奴は、変数名に a とか b とかつけるんだぞ

>>92に反論する前に、まず>>2を読め。

???
>>88は>>2を先ず読むべきだな。趣旨を理解していない。

読んでるってのw
頭悪いんじゃないの？
だからその趣旨は間違ってる、と言ってるんだと何度言わせるつもり

っていうか、人に偉そうに読め、とかいってる奴が読んでないんだよね。
いやただの行為として読んではいるのかも知れないが、文章を書いている人間の
論旨をまったく「読めて」ない。

>>95
アプリケーションハンガリアンの趣旨は間違ってるって、
つまり変数名は適当な連番でもいいってこと？

連番に意味がある場合を忘れずに。

>>95
明らかに頭悪いのはお前だよ。

横レスだが。

>>97
ローカル変数なんてわりとどうでもいいんじゃないのかな。
ループカウンタなんてi,j,kで十分だし、ローカル変数にいちいち
アプリケーションハンガリアンなんて使わないね。
そこに使わなければ意味が読み取れないほど関数が長くて意味が分かりにくいの
だとしたら、まずそっちを何とかすべき。

Joelの例は（しばしば彼の記事がそうであるように）、彼の主張を通すための
作ったような印象を受けるね。ありゃ、命名以前の問題としてクソコードだろう。

無論、クラス、メソッド、メンバ変数のようなものなら、意味をきちんと示す
分かりやすい命名をするべきだが、んなのは当たり前の話じゃまいか？

>>100
> 分かりやすい命名をするべきだが、んなのは当たり前の話じゃまいか？
当たり前だけどできてないから、どうやれば上手くいくかという方法論の話をしている。

>>101
例えばC++なら、それがアプリケーションドメインの特殊な概念を示す
共通的な何かなら、クラス化するなりtypedefするなりするのが正攻法でしょ。

Joelの言ってることは中途半端だし一貫性も無いように思える。
「当たり前のことが出来てない」んなら、「アプリケーションハンガリアン」
なる規則を導入することで、何かが上手く行くわけはない、よね？

正攻法がそんなに好きなのか？

読解力がない奴が多すぎるねしかし。

別にjoelって人が言ったからその通り、と言うことはもちろんないんだが、
joelって人は、（ちょうど"PriceInDollars"のように）変数名にその値の意味を
盛り込むことがアプリケーションハンガリアンだ、などとは少しも言ってない。

しつこいようだが、そんなものはアセンブラしかなかった時代から当たり前のように
やっていることだ。

ここの馬鹿連中は「タグ」だの「プリフィクス」だのといった表現が読み取れないのかねw

>>104
まぁ読解力に欠けるのは明らかにお前だけどね。

>>104
>読解力がない
よくわかってるじゃないか、自分のこと。

>>104
＞ユーザから来た文字列は(安全でない?Unsafe?文字列という意味で) プレフィックス"us"をもつ名前の変数に格納する。
＞HTMLエンコードされた文字列や、素性の安全なことのわかっている文字列は(安全?Safe?な文字列という意味で)プレフィックス"s"を持つ名前の変数に格納する。

＞安全でない?Unsafe?文字列という意味でプレフィックス"us"をもつ名前の変数に

＞安全でない文字列という意味でプレフィクスをもつ名前の変数



変数名に「安全でない文字列という意味」であるusというプリフィクスをつけよう

>>107
ひょっとしてネタじゃなくて本気で
「アプリケーションハンガリアンとは、変数名（やメソッド名）にその値の意味を盛り込むことだ」
(とJoel氏は主張しているのだ）と思ってるの？w

しょうがない、ならば質問。

　・では、「アプリケーションハンガリアン」と「システムハンガリアン」の違いは？
　　どっちも共通して「ハンガリアン」という言葉がついてるけどw

　・Joel氏はアプリケーションハンガイアンとは何か説明するくだりにおいて、
　　「タグ」や「プリフィクス」という、意味を狭める言葉をわざわざ使っているわけだが、
　　もし氏が「アプリケーションハンガリアン」という言葉を君が思っているような意味で
　　使っているとしたら、なんでわざわざそんな「不適切な」言葉を使ったと思う？

>>108
・システムハンガリアンとは
アプリケーションハンガリアンの勘違い品
大して意味もない「変数の型情報」を変数名に盛り込むよう推奨したもの

・タグやプリフィクス
アプリケーションハンガリアンの趣旨は「重要情報を変数名に含めれば、その部分を見ただけで間違いが分かって便利」
タグ（プリフィクス）がハンガリアン創生で使われてた手法なので、Joelもそれを推奨している

確かにJoelは別に「プリフィクス以外でもいいんじゃね？」とは一言もいってない。
が、絶対プリフィクスでなければならないとも言っていない

スレ民は「>>88みたいなのもアプリケーションハンガリアンの一種といえるだろう」と言ってるだけ

>>108
お前「意味」の意味を勘違いしてるだろ
>104と同一人物？

Joel氏や他の人間が言っている「意味」ってのは、usやsのような超重要情報
お前が言ってる「意味」は単に変数名NameやMoneyのようなもの

お前の言うとおり変数名に意味をもたせるのは当たり前
アプリケーションハンガリアンは一歩進んで「重要情報も変数名に含めろ」っていうもの

>>109
だからそれが間違ってるって言ってるのね。
読解力がなさ過ぎるだろう、と。
本当に義務教育修了してるのかねこういう奴らってw

繰り返すように、別にJoel氏が言ったからどう、ってことは全くないんだが、
Joel氏が言ってるのは正確にはこうだよ。

[ハンガリアン]
識別情報をあらわす統一的な略号を名前に付加する命名法。

[システムハンガリアン]
ハンガリアンのうち、名前に付加する識別情報が型情報のもの。

[アプリケーションハンガリアン]
ハンガリアンのうち、名前に付加する識別情報が意味論的なもの。

念のために言っておくけど、この話の肝は、ハンガリアンとは、

　- 統一的な略号を名前の一部に含ませる命名法であること
　- 略号の表すものは識別情報であること

であることに注意が必要だよ。

とりあえず111が読解力なさすぎなことだけは分かった

>>111
途中送信しちまったよ
お前の日本語能力欠如しすぎ

＞だからそれが間違ってるって言ってるのね。
その「それ」とは何を指しているのか明確にしろ。話はそれからだ

それが間違ってる
こういう奴ら
この話

議論の場で指示代名詞を連発する奴にろくな奴はいない

それ ＝ 109の最後の行

>>111
＞[アプリケーションハンガリアン]
＞ハンガリアンのうち、名前に付加する識別情報が意味論的なもの。

>>88
＞通貨ならそこまでしなくてもPriceInYenとかPriceInDollarsってすれば済む。
＞ynPriceとかdlPriceとかに合理性は見出しにくい。

88はYen、Dollarsに「この値は日本円換算」「この値はドル換算」という意味論的なものを付けているが？

三歩歩くと全部忘れる鶏頭なのかねw
だから、そこに「ハンガリアンのうち」と前置きがあるのを読めないのか？w
ハンガリアンとは何かも直前にも書いてあるし、直後にも念を押してるじゃないかだから

へ？ああ、馬鹿なのか

つまり>>88のやり方を「アプリケーションハンガリアンのようなもの」と評価されるのが嫌なんだろ
>>117にとってはアプリケーションハンガリアン様はもっと高尚にして神聖で、改変の許されないものなんだよ

なんかもう呆れた通り越してほほえましいなｗ
形式ばっかりにこだわって本質が見えてないというかなんというか

歴代ガンダムをまとめて「ガンダム」って呼んだら、ガンダムは初代だけ！ZはちゃんとガンダムZという別物で
とか講釈始められた気分だ

>>111にある「ハンガリアン」ってなんだ？
システムハンガリアンやアプリケーションハンガリアンと区別したいので解説頼む。

あんまりいじめるなよ
馬鹿なんだから

>>121
別に俺の解説を聞いても仕方がなかろう。

Joel氏がなんと言っているかを調べたければJoel氏の文章を自分で読解するしかないし、
一般的な用語法が知りたいなら自分で「調べる」ほかないでしょ。

っていうか、俺の（Joel氏がその三者をどう区別しているか、に対する）見解は111に
表現されていると思うが。

君は「〜のうち」っていう表現の意味するものを知らないの？w
君は「人間のうち、チンコがついているのが男性である」という文書を読んだときに、
同じように「人間と男性の区別って何だろう？」という疑問をもつの？w

だとしたらかなりのお馬鹿さんだよ。

>>123
ごめん
痛々しくなってきた

88「人間？哺乳類でいいだろ」
スレ民「哺乳類ってわけかたでもいいな。人間ってカテゴライズするのとやりたいことは似てるな」

お前「似てない！全然似てない！」
スレ民「カテゴライズして名前付けるって意味では一緒だろ」
お前「全然違うんだい！」

>>123
ごめん
俺らもう「読解した」からお前の説明一切いらないや
消えて＾＾

>>124
いや悪い、義務教育レベルの読解力を欠く連中に痛いとおもわれても何も堪えないよ。

しかし、何かの国際機関の調査で日本の児童生徒の読解力は先進国中最低だ、
って調査が出てたと思ったが、本当に由々しき問題だよこれ。

そもそもJoel氏が件の文書を書いた動機は不当に貶められている（と氏が考えている）
アプリケーションハンガリアンの価値の復権にあるのだが、ここの馬鹿連中は
それが少しも読めてない。

要は氏は唾棄すべきはシステムハンガリアンであってアプリケーションハンガリアンは
称揚すべきものだ、と考えているわけ。
だからそのためには、アプリケーションハンガリアンの、システムハンガリアンとの
違いを強調して読者に理解させる必要がある。

アプリケーションハンガリアンで命名された変数にこめられるものが「意味論」であることを
強調するのはそのためだ。

全く別の言い方をすれば、氏は
「アプリケーションハンガリアンによる命名には意味論的な違いの表象を含む」
と言っているのであって、
「意味論的な違いの表象を含むものがアプリケーションハンガリアンだ」
などとは言ってない。

ようはここの馬鹿どもは
「郵便ポストは赤い」
という文章を
「赤いのは郵便ポストだ」
などと間抜けでトンマな誤読をしているというわけだ。

トンマな誤読をしていると思い込んでるだけ

＞「意味論的な違いの表象を含むものがアプリケーションハンガリアンだ」
こんなこと誰も言ってない

>>88に対し
お前のも意味論的な違いの表象を含めているから、アプリケーションハンガリアン『のようなものだ』
だからアプリケーションハンガリアンが必要ないのではなく、たまたまお前が天然で似た表記ルールづけを使っていたので「お前は必要性を感じなかった」にすぎないよ

と言っただけ

>>88-92の流れを見て勘違いできるのが凄いよなぁ

>>128
しっかし馬鹿だなホント

「アプリケーションハンガリアンのようなもの」≠「アプリケーションハンガリアン」

別の言い方をすれば、否定しているのは「アプリケーションハンガリアン」であって
変数名に意味論的な差異をこめることは否定してないの。

だから言ってるじゃん何度も。
意味論的な差異を変数名にこめるのがアプリケーションハンガリアンではない。
Joel氏もそんなことは全然言ってないの。

郵便ポストは赤い（（アプリケーションハンガリアンによる命名には意味論的な差異の表象を含む）
といっているのであって赤いのが郵便ポストだなんていってないってのw

ようするにプレフィックスの形態をとっていないものを
（広義の）アプリケーションハンガリアンと言ってよいかどうかという話だよな、元々。

その通り。

言ってよいかどうかは誰も回答不能だろうけど、一般には「アプリケーションハンガリアン」
という言葉はプリフィクスやサフィックスなどのタグで意味論的な差異を表す
命名法のことを指す。

Joel氏もそう言ってる。

>>130
だからさぁ、何したいの？目的がわからん

128である俺（やほかの連中）に「何を理解させたくて説明してる」の？
俺は
・アプリケーションハンガリアンは有用だね
・>>88のやり方はアプリケーションハンガリアンみたいなもんだね。それでいってもいいんじゃね？
としか思ってないんだが？

>>132
ぶはｗｗ
ただそれだけのことをだらだらわけのわからん理屈こねくりまわしてたのかよｗ
何したいのかｻｯﾊﾟﾘわからんかったわ

ごめん。
俺も痛々しくて見ていられない。

つまり、ガノタが一般人に、初代ガンダムとガンダムZの違い〜という俺の例えはあってたわけだな
アホくさ
ただの狂信者か

Joel氏もそう言ってる（ｷﾘｯ

な状態だなほんと

つまり>>88と>>90を読んで

大抵の人
「概念的にはたしかに90の言うとおり、アプリケーションハンガリアンと『同様だな』
アプリケーションハンガリアン（のようなもの）だと言っても過言ではないだろう」

132
「プリフィクスの形態をとってないものをアプリケーションハンガリアンと呼ぶなｒｆｔｇｙふじこ！
>>90はキチガイ！勘違いやろう！俺が説明してやる！！！」

まあ鶏頭クンたちは落ちついて>>88に後続するレスを読め

例えば>>89-90
それでもまだ>>138のような寝言が言えるならたいしたもんだよ。
たいしたもん、ってのはもちろん嫌味だけどねw

>>139
89書いたの俺なんで口挟むぞ
あくまで88の「プリフィクスは見づらいからアプリ（略）は駄目駄目」という感想に対して、重要である趣旨そのものを説明しただけ
「アプリケーションハンガリアンとは何か」という問われかたをしたときはプリフィクスのことまで含むのは当たり前だろ

子供を諭してたら横から「その説明は哲学的に言うと違いますねﾌﾌﾝ」とか言われた気分だよ

>>88
変数名のうち「円」,「ドル」を表す部分がどこかわからないじゃん？
もちろん少し考えればわかるけど。
変数名をみて少し考えなきゃならないと、可読性が下がってしまう。

でも、変数名の頭の2つの小文字に意味を持たせるというルールにすると
すぐに（変数名の最初の小文字を見れば）意味が理解できるので
合理性はそれなりにあると思うよ。

間違ってると思うよ。
その意見は、「略号と意味を結びつけるコストがゼロである」という
実際にはあり得ない前提に立っている。

それが言いすぎだとしても、少なくとも略号を意味をリンクするコストが、
明示的な命名を読解するコストより低いという前提の物言いではあるわけだ。

これがいかにナンセンスな前提かはプログラマなら経験的にわかるでしょ。
一年後にその訳のわからん略号の溢れるコードをよむ場面を想像してみ。
運よく略号の意味がドキュメント化されていれば少しは救われるが、（それでも
訳のわからん略号を覚えるのは結構骨だ）もしそれすらなかったとしたら･･･

そもそも「円」や「ドル」を変数名で表す必要なんてない、ってことで >>87 なんだけどね。
ハンガリアン記法って、型システムが貧弱なC言語とかのための、人力で型システムを一部代行する運用規則だから。

C++みたいな言語で、円とドルが複雑に混在してるコード書くんだったら、
Currency<Yen> price;
みたいにしちゃうほうが、ずっとすっきりする。

人間が目で見て調べなくても、処理系が自動で検査してくれるし。
変換用の演算子とかも定義しとけば、必要に応じて自動で変換もしてくれるだろうし。

>>141
別に88のなかで「変数名の最後の単語がkind情報をあらわす」と決めてるかもしれないぞ？

>>143に同意。

>>144
そういうのは当然略称一覧（ただのテキストファイルで十分）みたいなのを
保守しつつやるんだろう。
C++のように抽象や概念を直接コード化できれば一番いいのだが、
出来ないんなら、コード化できなかったルールをどこかに書くしかない。

通貨の例が不適切だったのでは？
つまり、システムハンガリアン的な要素も含んでいる。

しかし、>>２の安全であるとか安全でないとかであれば、
まだ使い道はあると思う。

たとえば、文字コードだとどうだろう?
S-JISならsHoge, EUC-JPならeHoge, UnicodeならuHoge
結局は同じかな？

>>143
＞変換用の演算子とかも定義しとけば、必要に応じて自動で変換もしてくれるだろうし。
演算子のオーバーロードは危険だと思うがな〜

>>144
＞別に88のなかで「変数名の最後の単語がkind情報をあらわす」と決めてるかもしれないぞ？
たとえば、香港ドルだとPriceInHongKongDollarとなり、
最後の単語だけみると、ＵＳドルと間違えるかも知んないぜ？
>>88がいいたかったのは、変数名の最後より最初のほうが見やすいんじゃね？ってことでしょ

日本がハンガリーに負けそうだお

【いくぞ】一番クリックした国が優勝【30,000,000click/min】
http://wwwww.2ch.net/test/read.cgi/news4vip/1194876671/

最強のOCR兵器開発が急務かな

すれ違い。。

文字コードに関しては、内部は全部 UTF-8 で統一、読み書きのときに変換する、ってのが有効じゃないかな。

あえてやるなら
CodedString<SHIFT_JIS> hoge;
とかだろうけど。
適切な変換演算子定義しとけば、特定の文字コード仮定した処理なんかも期待通りに動くだろうし。
演算子定義しない場合でも、文字コードの違いを型の不一致として検出してはくれるよね。

なんでよりにもよって内部がutf-8なわけ？
UTF-32とかならわかるけど、内部コードがMBCSってありえなくね？

理由を書かないと独り言だぞｗ

>>150
perlとかrubyとか。

ハンガリアン記法でstring& fnameは、どの様に書いたらｲｲﾃﾞﾂｶ

システムな方ならfnameというのがファイル名だとしてfnTempとかfnDataとか
そんな感じじゃね？

アプリな方ならsTempFileとかsDataFileとかか。

しまった、アプリ<->システム取り違えてた

良スレ

1,2,ハンガリアン
2,2,ハンガリアン
ハンガリアン　ハンガリアン♪

システムハンガリアンの規約でやってたときは、すべての変数にプリフィクス付けてたが
アプリケーションハンガリアンでもすべてに付けないといけないんだろうか？
一部の重要な箇所だけでいいかな。
でもそれだとプリフィクスに相当する部分が左辺と右辺で違うソースだらけになって
ハンガリアン使ってる箇所も気付かず見逃してしまうだろうか。

システムハンガリアン：アプリケーションハンガリアン
じゃ分かりにくいから、システムの方はWindows
偽ハンガリアンとか呼びたい。これならいかにも悪
そうだし悪くなった原因も明確

システムだろうとアプリだろうとクソはクソ
prefixで変数の素性がわかって便利〜♪なんてのが許されるのは
FORTRANだけなの！
中途半端に変なのつけずに素直に変数名そのものに情報を盛り込みましょう

それがアプリケーションハンガリアンじゃね？

違うよ

接頭辞は１文字じゃないといけないとか
短縮形じゃないといけないとか思ってないか？

prefixという形態そのものがクソなんだよ
付随的属性は後ろにつけるのが本来の姿だし読みやすいのだ
これは日本語だろうと英語圏だろうと同じ

形容詞は日本語でも英語でも前に付けるもんだが・・・。

ﾊﾝｶﾞﾘｱﾝでprefixにするのは形容詞相当部分じゃないな、普通
むしろ 〜of xxx とか 〜in xxx のxxxに相当するpostfix的属性のことが多い
それを無理に前に持ってきても読みづらくなるだけで大して役にたたない
まあハンガリー語ではどうか知らんがｗ

日本語だと前だろ？

後ろだな
rwMax, colMaxは日本語では「最大行数」、「最大カラム数」だ

行数の最大値、カラム数の最大値、だろ。of に相当する使い方すると。

言い換えただけ、本質はそういうこと

nElems は number of elements だし

まあ、元の状態で前か後かなんてどうでもいいってことだ。
「要点は最初に書く」 という離心的な発想は極めて合理的。
最後に書いた方が・・・なんてのは話下手のやること。

形容詞じゃないじゃん・・
number of elements = element number なら
むしろelementのほうが形容詞的存在じゃないのか

普通は形容詞じゃないって言ったのはお前の方じゃん・・・

そうだよ
形容詞だって主張したのはお前じゃん・・

形容詞じゃないという主張に関しては、
ああ、そういやそうかもなあ、と思った。
だからそれにそって話をしたら叩かれた・・・。

fnTexture // ｸｿ
TextureFileName // ｶｺﾜﾙｲ
texture_filename // まあ普通だな
textureFilename // 俺はこれかな

元々は数十KBのメモリ空間にアセンブラやCでガリガリ詰め込んでた頃の
テクニックだよ。
まあとにかくお前ら「実録！天才プログラマー」を入手して
考案者本人の話を読んでみなよ。

この本は他にもBASICを書いていたころのビル・ゲイツとか、PostScriptの開発
者とか世界で初めてスプレッドシートを開発した人とか、今では名前すら残っ
ていない怪しげな「自称天才」とか、いろいろ面白い話やら手書きのメモやら
が載ってるから買って損はない。

訳者がコンピュータ畑の人じゃないので少〜し読みにくいけど。

>元々は数十KBのメモリ空間にアセンブラやCでガリガリ詰め込んでた頃の
>テクニックだよ。

そこまではさすがにさかのぼらないだろ
その時代のPC上のASMやCの言語仕様ってのは
変数名は先頭6文字まで識別とかその程度だから
prefixなんかつけてたらかぶっちまう

textureFilename = sourceFilename; //OK
textureFilename = sourceDirectoryname; //NG

fnTextureFilename = fnSourceFilename; //OK
fnTextureFilename = dnSourceDirectoryname; //NG

上でも普通は問題ないが、下なら見た瞬間にfnとdnの意味は分からなくても、なにかおかしいとは感じられる。
思考することなく脊髄反射で判定できるので、頭が悪い人には有効だと思われる。

ああ、でもよく考えると8086に移りたての当時は
np (near pointer)/fp (far pointer) だけはつけてたな
これがないとときどきわけわかんなくなったｗ

>>180
その程度のくだらない例しか思いつかないのかよ
頭が悪い人っておまえのことだろ、もう帰っていいよ

＞頭が悪い人っておまえのことだろ
正解。だから色々、小細工しようとしてます。
周りと比べて明らかにコードを理解する能力が低いって自覚してる。
他人のコード読むときに書き直しながら理解して、後から戻すなんて無駄なこともしてる。

たぶんループしてる話だとは思うんだけど、
アプリケーションハンガリアン的なものっていうのは、使っても問題ない場面を
弁えて抑制的に使う分には確かに有用な場面もあるんだよね。

問題なのはフールプルールじゃない、つまり「馬鹿の一つ覚え」的に乱用して
意味不明な記号あふれる読解不能コードを生産する蓋然性があるってことで。

アプリケーションハンガリアンの言う所の「prefix」って
別に無理に短縮形にする必要はないんだろ？

そりゃおかしい。
短縮しないのならそもそもprefixにする必要もなかろう。

何で？

プレフィックスが左右で同じかどうか見るだけなんだから
短縮してなくても問題なくね？

長いと打つの面倒だろ

インテリセンスで

プリフィクスにしてもしなくても長さは大して変わらないと思うが・・・

文句あるんならJavaでも使ってろよ。

？？

>>179
シモニイがXerox PARCにいてALTOで動くBravoを書いたころ、
ビル・ゲイツはAltair 8800で動くTinyBASICを書いていた。
その3年後、ベル研のカーニハンらによってC言語が公開された。
時代的にはそんなもの。

シモニイはMicrosoftに移る前から独特な識別子の命名規則を
編み出して使っていた。MSに移った頃は
「あのハンガリー人の書くコードの変数名は変わってる」
と噂されていた。

それって個人的に使ってただけで公式に普及してたわけじゃないのでわ

普及しだしたのはDOSの最後の方のかWINの最初の方のを
作ってたときだったか。

今後、登場する言語にはこんな機能がつくようになりますように。
http://www.kaz.appi.keio.ac.jp/~syl/Hungarian/

こいつは C でプログラム組めないんだろうな。

ハンガリアンチョップ！

新しい言語は強いtypedefを持ってるだろ

ポインタなのかリファレンスなのか実体なのかってのの判別は、
typedefでは解決できないんじゃ。

元々も

　「意味が違う情報を保持する変数には違う印を名前に付ける」

が変質して

　「型が違う変数には違う印を名前に付ける」

とクソになって、最後は

　「型と製品と所属モジュールの情報をコード化してすべての変数に付ける」

というありえないgdgd状態に。

元々の論文の "type" は変数の種類、分類を表していたのに
変数の型を表していると誤解されたのが原因と聞いてるけど

2も見ねーで語るなよｗｗｗ

今度就職した会社は、完全にシステムハンガリアンを採用しているみたいです。

VBのソースなんだけど、、、

cls
fnc
sub
pub
str
CNST_
asp

とか。で、これらを組み合わせて使ってるんだよね。
定数なんか大文字にしているのに、わざわざCNST_付けてるのって意味ない。

クラスが全部clsなのとか……。

C++でやってた時、m_clsXXXとゆうのは結構あった。
VBだとm_oXXXもしくはm_objXXXが多かったけど。

アンチハンガリアンだが、VB6やVBAみたいに
型と変数名の名前空間が分離していないくせに
大文字小文字も区別しないクソ言語使ってるときには
安直に衝突を回避する策として使えることが分かった。
VB.net以降は少しはマシになったのかな？使ってないから知らんけど。

>>207
VBの糞仕様は指摘どおりなんだが、>>204みたいな方式は冗長すぎる頭の悪いやり方だよ。
全然有用じゃない。

普通はこんな感じでやれば糞仕様のVBでももう少しスマートにできる

- 自作クラスはcでプリフィクスする。

- enumは使わずに標準モジュールの定数で代用する。

- 基本、変数名に余分なプリフィクス・サフィックスは付けない。

- ただし、他所製のコンポーネントでクラス名と同じ名前を変数名に使いたい場合は
　IDEの流儀に従ってインスタンス名を数字でサフィックスする。

VB6時代だと、画面の標準部品は、MS仕様にあわせていたけど
アレはアレで便利だったと思うけどな。

txtHoge <-- テキストボックス
lblHoge <-- ラベル
btnHoge <-- コマンドボタン

まあ、今はやらんけど結局
hogeText
hogeLabel
hogeButton

になっただけなんだ。

Java本でhogeButtonみたいな例を初めて見たとき、
なんだ普通の英語の語順で書けばいいんじゃないかと開眼した。
ハンガリー語という仇名には、ある種の皮肉というか悪意がこもってるかも。

>>209
既出だと思うけど標準コントロールのハンガリアン表記は結構有用だと思う。

「なんて名前つけたっけ？」って時もインテリセンスを検索的に使えるし。
ベタにTextとか書くと"text"って単語がコントロール名に使いにくくなるし。
英語的にも関係代名詞使った構文みたいな語順になるから意味が頭に入りやすいし。

それでもtextTextBoxのほうが好きだ。
自作コンポーネントの変数追加したら、そこだけ浮いちゃうんだろ？

>>210
でも先頭に無いと並んで書いた時に読み辛いんだよね

grep して調べたら、Functionプロシージャなのに、sub〜のプレフィックスが付いてて、もはやルールが崩壊してるんだよね。

しかもその会社は、DBのテーブルやフィールドが全て大文字で、アンダーバーの区切りなし、母音省略で、かなりやりにくいわ。

辞めた前の担当者だけとかだったらいいけど、会社としての方針なら最悪・・・。

ttp://www.maroontress.com/Hungarian/

よくある図式

普通のコードの書き方を覚える
↓（窓の壁）
システムハンガリアンを知る
↓
意味わかんねーし糞うぜー
↓（情弱の壁）
アプリケーションハンガリアンを知る
↓
俺も世間も駄目扱いしてたけど実はそうじゃなかったのか？
↓↑（対立）
でもよくよく考えると駄目じゃね？

ポインタだけはpHogeとかつけるな。
ppHogeとか付いて無いと分かんなくなる。

♥

ハンガリー人を右に

ダブルハソガリアッ上

家電.com
ＨＰ
http://Kadencom.chochouo.com

保守

test

test

窓辺ななみ