ハンガリアン記法 [part1]

1 ：07/08/21 〜 最終レス ：11/08/16

ハンガリアン記法ってどうよ　(使ってる人・使ってない人)
さぁ意見を
↓

2 ：

結論
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

3 ：

まぁ語れよ

4 ：

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

5 ：

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

6 ：

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

7 ：

（　＾ω＾）断る>>6

8 ：

逆ポーランド記法だろ

9 ：

言い切れる。
終了

10 ：

結局のところ（特に日本では）、「MSが牽引しているからイヤイヤ」という感情面から入ってるバカが多いような気がするんだけど。
個人的にはどっちでもいいと思うけど、むやみやたらに毛嫌いする変な人が多い。
もう見ただけで「うわーもうやってらんね。俺様のスーパー技術者人生としてのプライドに関わることだから。絶対こんなのツカワネ」。
ハンガリアン記法はともかく、
youcanfly()やyou_can_fly()より、YouCanFly()の方が読みやすくないかな？
俺が日本人だから？ 英語に馴れてる人なら前者の方が読みやすくなるんだろうか（外人は前者の人が多いと思う）。

11 ：

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

12 ：

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

13 ：

>>10
読みやすい読みやすくないじゃなくてなんであるかによって使い分ける。
例として、
大文字で初めてCamelCase → クラス名
大文字だけを使う → 定数
小文字で初めてcamelCase → メソッド名
全部小文字で単語間に_を入れる → 変数名
みたいな感じ(あくまで一例、他のルールももちろんあり得る)。
ハンガリアンではないけど見た目で何かすぐわかるので、
ハンガリアンの考え方は取り入れてる感じ。

14 ：

>>11
ちがうだろ、>>9のはjoelで全て語り尽くされてるって話だろ？
俺もアプリケーションハンガリアンは推奨派だし使う。
ちなみにシステムハンガリアンは有害。

15 ：

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

16 ：

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

17 ：

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

18 ：

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

19 ：

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

20 ：

そうじゃない？

21 ：

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

22 ：

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

23 ：

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

24 ：

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

25 ：

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

26 ：

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

27 ：

馬鹿なスレだな

28 ：

そりゃ part1 の時点でもう

29 ：

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

30 ：

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

31 ：

俺もJavaで>>18みたいのは見た事無いな。
配列とかリストの変数名を複数形にするのも一種のハンガリアンかな？

32 ：

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

33 ：

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

34 ：

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

35 ：

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

36 ：

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

37 ：

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

38 ：

そりゃ star だ。

39 ：

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

40 ：

ストリング

41 ：

ストレングス

42 ：

ストリップ

43 ：

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

44 ：

>>36　ｋｗｓｋ

45 ：

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

46 ：

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

47 ：

アプリケーション版画利案ならいいと思うが、最近流行のアノテーションを
使って型（type）チェック以上の種別（kind）チェックができるんじゃないかな？
ダメなコードが変に見えるように、ならアプ版画利案で十分だけど、
実際のところコンパイラが自動チェックすればもっといい。
　@[kind = my.unsafe]
　string read_param(string key);
　
　@[kind = my.safe]
　name = read_param("name");
とか書いて、
　mylanguagecompiler -Wkind my.code
とかで typecheck ならぬ kindcheck が勝手にかかれば版画利案の醜い字面に
耐えることなく同じ効果を享受できる。

48 ：

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

49 ：

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

50 ：

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

51 ：

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

52 ：

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

53 ：

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

54 ：

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

55 ：

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

56 ：

ぬるぽ

57 ：

次スレタイトルはこれで
土旦土旦 ハンガリアン墓場 旦土旦土

58 ：

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

59 ：

あげ

60 ：

がっ　

61 ：

型情報が重要なこともしばしばあると思うんだけどなぁ
m_strName
見た瞬間に、String型でメンバー変数なのね。って分かる
他人のプログラムの文中に
Name
って変数が出てきた時って、みんなどうやって情報集めるの？
カーソルあわせて型とかが出るまで待つの？

62 ：

何の脈絡もなく突然変数名が出てきたりしないでしょ。
だいたいは関数とかクラスの宣言見ればわかるし。
出所不明な変数が突然出現したら、一体どこから来た何に使う変数なのかってのを調べなきゃいけない。
型だけわかったって足しにならないよ。

63 ：

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

64 ：

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

65 ：

型情報なんざ、コンピュータに検査させれば良い。
メンバ変数かどうかも同様。
まさかメモ帳で開発してるわけじゃないだろ？

66 ：

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

67 ：

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

68 ：

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

69 ：

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

70 ：

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

71 ：

ハンガリアンはもう古い。
今はモンゴリアン。
チョップ。

72 ：

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

73 ：

エディタが強力になってもハンガリアンの代替機能なんてほとんど使わないでしょ。
例えばインテリセンスとかでいちいち型確認してる？
しないね普通。
つまり最初から必要なかったんでしょ。
パラノイア気質の奴が最初から必要もないものを強迫的に必要だと思い込んじゃっただけっぽい。

74 ：

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

75 ：

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

76 ：

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

77 ：

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

78 ：

パラノイア=MS信者
いちにいハンガリアン、にいにいハンガリアン

79 ：

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

80 ：

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

81 ：

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

82 ：

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

83 ：

システムハンガリアンなんて確実にいらないでしょ。
↓の人が、本物のハンガリアとはアプリケーションハンガリアンのことで、
こちらは有益だって力説してる。
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
でもどうかね。
確かに一理はあるし、確かに複数の座標系があるときにどの座標系かを区別するような
用途にはある程度適合的かもしれんが、やはり正攻法じゃないと思うな。

84 ：

>>83
>>2

85 ：

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

86 ：

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

87 ：

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

88 ：

通貨ならそこまでしなくてもPriceInYenとかPriceInDollarsってすれば済む。
ynPriceとかdlPriceとかに合理性は見出しにくい。
あるいは、仮想的な概念として「価値」を考えてそれを型にするのも一つの手だね。
Price.InYenとかPrice.InDollarみたいな感じ。
この考え方は上の複数の座標系にも応用できると思う。

89 ：

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

90 ：

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

91 ：

仮にそれが正しいのなら（いや間違ってると思うが･･･）
そもそも「アプリケーションハンガリアン」などというカテゴライズには
最初から何の意味もないことになるな。
だってPriceInYenとかPriceInDollarsなんてのはごく普通の何の変哲もない
命名に過ぎないじゃないか

92 ：

>>91
君がたまたま自然に「アプリケーションハンガリアン」を受け入れていただけの話
知ってか知らずかね
何も考えない奴は、変数名に a とか b とかつけるんだぞ

93 ：

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

94 ：

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

95 ：

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

96 ：

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

97 ：

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

98 ：

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

99 ：

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

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
新C言語を作ろう
Vista対策 その２
【動くんか？】摩訶不思議なコード【何語？】
エスパーが質問に答えるスレ