アカウント名:
パスワード:
＞X座標を保持する変数にはpx、重さを保持する変数にはkg
用にそれぞれ別の型を宣言してやればいいんですよ。
>そうすれば、pxA + kgX という式は
コンパイラがワーニングかエラー吐いてくれますよ。こんな機械に判定させておけば良い物に人間が煩わされるなんて馬鹿馬鹿しい。
普通ここまでやらないのはパフォーマンスがどうとか使い勝手がどうとかいう話が絡んでくるからで、アプリケーションハンガリアンなんてもんは所詮妥協の産物ってこった。
おっしゃる通りで、どっちに寄りかかるにせよ、狂信的な原理主義者に現場が振り回されるのだけは勘弁して欲しいものです。
しかしこの辺の議論を読んでいて思ったのですが、最近のトレンドではハンガリアンという代名詞を持ち出すまでもなく、変数や関数に「意味のある名称」をつけること自体、もはや時代遅れとされつつあるのでしょうか? 元々ハンガリアン記法が忌み嫌われていた一番の理由は、処理系の都合に過ぎない (組み込みの) 型という概念の為だけに名前付けが冗長になってしまうことであり、それは名前に対するセマンティクスの重視と、読みやすくメンテナンスしやすいプログラムソースの追求という命題に対する裏返しなのだと思っていたのですが。
＞変数や関数に「意味のある名称」をつけること自体、もはや時代遅れとされつつあるのでしょうか?
そんな極端な。
ハンガリアンは複数の意味を無闇やたらにオーバーロードした結果、意味が通りにくくなって本末転倒だから嫌われてるだけだと思いますが。
コンパイラの型チェックに頼らなくても、今時はドキュメント自動生成方法が充実していたりIntellisenseのような手段も一般的になって人間が変な手間をかけなくても機械の方がなんとかしてくれるってことだけだと思います。
ハンガリアン記法が（snip）それは名前に対するセマンティクスの重視と、読みやすくメンテナンスしやすいプログラムソースの追求という命題に対する裏返しなのだと思っていたのですが。
笑わせる。「px」とかのわけのわからない一文字化略記が今時の「読みやすい」？笑う。ちゃんと略さないで書けっての。
と、いうことは、略されてさえいないのであれば、prefix はアリだと言うこと? column か row かの区別も型を設けて対応すべきという議論があったけれども、 prefix が「column」「row」と略されずに記されれば文句はないと言うこと?
御意。個人的には、その名前が用いられる文脈上において十分に意味の通る名前であるならば、それで十分だと思っております。
今時、短くする必要なんてないし、前置記法にする必然性もない。
別に無理して長くする必要もない。意味がわかればそれでいい。前置記法で短く、わかりやすくすることはできるし、わかりやすいならそれは有用なことだし、短くてわかりやすくなるものをあえて使わない必然性はない。kgWater, klWater, klpsWater, kgcmWaterPressそれぞれ、水量(kg), 水量(kl), 流水量(kl/s), 水圧(kg/cm2)な。
型を記述するシステムハンガリアンはコンパイラに任せてもいいけど、コンパイラは識別子の意味をチェックしてはくれない。アプリケーションハンガリアンでやれば済むところを、いちいち型定義してコンパイラに無理矢理やらせようなんて、方向を間違ってる。
意味を記述するところを、型定義で代用しようとする方向性が間違いだと言ってるんです。意味ごとに型を作って、型変換メソッドを起こしてまで機械にチェックさせるのはコストの無駄。
コンパイラ以外にチェックするものをお持ちでないのですか?
意味をチェックしてくれる機械が地上に存在するというなら、示してみなさい。
別に prefix でも postfix でもどっちでもいいよ。名前にそれを含めることを「必要」と考えるか「あった方がいい」という程度に捉えるか、別の手段を採ってでも「不要」とすべきと考えるか、という話。そんだけのことのためにわざわざ型を宣言するのが理想というのはまさに「別の手段を採ってでも「不要」とすべき」という考え方な訳でしょ。
だからどっちも極端なんだってば (^_^; 。
型定義もあんまり数多くなりすぎればやっぱりめんどくさいし、細かくやり過ぎればかえってメンテナンス性が落ちる (引き継いでソース管理することになった人が設計を理解しきれなくなる) ということも十分あり得る訳。
そしてそれは「ハンガリアン記法」に代表されるような業務単位での「お約束事」でも同じこと。略記的前置詞は外から引き継ぎ要員連れてきたらそれまた全部覚えさせなきゃならない。MS が「狭義の」ハンガリアン記法を定義したのだって、会社単位・業務単位で記法がばらばらになってしまったら保守コストが上がることを理解していたからだ。でもそんなもん統一できるのなんてそれこそ組み込みの型名とスコープぐらいのものでしかなかった。
大体元よりコピペどころか近頃のエディタは名前の補完機能も優れていてめちゃめちゃ便利になってきているって言うのに、今更長い名前を使うのが面倒くさいなんてこともないでしょうが。最初の 2, 3文字打ち込んで、あとは補完候補を選んであげれば済む。それでソースはさくさく入力できてしまう。それの何が不便だというのか?
それはごもっとも。しかし、それを解決するための手法として、「ハンガリアン記法」と呼ばれる (あるいは揶揄される) やり方が適切であると言えるのか。問題が「長ったらしい」ことではなくて、「煩わしい」ことであるならば、それはむしろローカルルールの略記法では悪化してしまうのでは?
名前の意味の保持を重要視するのであれば、あとは名前空間の活用という手段もあります。クラスや関数を定義し、その中に文脈を閉じ込めるという手段もあります。質量と体積がごっちゃになるのが困るのであれば、質量しか扱わないクラス、体積しか扱わないクラスを定義し、文脈を分けることが可能であるかどうかを検討してみてもいい。もちろん、そうそう分断が容易ではないケースが少なからずあるからこそ、こういうことを問題にしているのであろうかとは思いますが。
>ひょっとしたら一人一派かもしれません
確かにハンガリアン派は一人しか居ない気がするな。それも何かコンプレックスを抱えたキモいのが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
ハンガリアン記法とか (スコア:0)
Re: (スコア:3, 参考になる)
char szHogeHoge[64]のようなシステムハンガリアンを使うことについては、僕も大嫌いですが。
Re: (スコア:0, すばらしい洞察)
同意しない。だって、そういう目的なら、それ用の型を準備して使えばいいわけで。
暗黙に決めた名前ルールでどうにかしようなんて馬鹿げてて、型でシステマティックに解決するべきです。Javaのような部類の言語（静的型付言語）ならそれができるよね。
けっきょく、ハンガリアン記法なんてものは、静的に型を明示できない言語で型名を変数名に入れているだけだよね。しかもアドホックに。
Re: (スコア:0)
例えば、X座標を保持する変数にはpx、重さを保持する変数にはkgというプリフィックスを付けましょうということです。
そうすれば、pxA + kgX という式は誤りである可能性が非常に高いということが字面だけでわかります。
これは型でどうこうできるものではないのは理解いただけると思います。
(むろん言語のほうでどうにかすべきで、curlではなんとかしていますが)
いや、存じてるでしょ (スコア:0)
＞X座標を保持する変数にはpx、重さを保持する変数にはkg
用にそれぞれ別の型を宣言してやればいいんですよ。
>そうすれば、pxA + kgX という式は
コンパイラがワーニングかエラー吐いてくれますよ。こんな機械に判定させておけば良い物に人間が煩わされるなんて馬鹿馬鹿しい。
普通ここまでやらないのはパフォーマンスがどうとか使い勝手がどうとかいう話が絡んでくるからで、アプリケーションハンガリアンなんてもんは所詮妥協の産物ってこった。
Re:いや、存じてるでしょ (スコア:2)
おっしゃる通りで、どっちに寄りかかるにせよ、狂信的な原理主義者に現場が振り回されるのだけは勘弁して欲しいものです。
しかしこの辺の議論を読んでいて思ったのですが、最近のトレンドではハンガリアンという代名詞を持ち出すまでもなく、変数や関数に「意味のある名称」をつけること自体、もはや時代遅れとされつつあるのでしょうか? 元々ハンガリアン記法が忌み嫌われていた一番の理由は、処理系の都合に過ぎない (組み込みの) 型という概念の為だけに名前付けが冗長になってしまうことであり、それは名前に対するセマンティクスの重視と、読みやすくメンテナンスしやすいプログラムソースの追求という命題に対する裏返しなのだと思っていたのですが。
むらちより/あい/をこめて。
Re: (スコア:0)
＞変数や関数に「意味のある名称」をつけること自体、もはや時代遅れとされつつあるのでしょうか?
そんな極端な。
ハンガリアンは複数の意味を無闇やたらにオーバーロードした結果、意味が通りにくくなって本末転倒だから嫌われてるだけだと思いますが。
コンパイラの型チェックに頼らなくても、今時はドキュメント自動生成方法が充実していたりIntellisenseのような手段も一般的になって人間が変な手間をかけなくても機械の方がなんとかしてくれるってことだけだと思います。
Re: (スコア:0)
笑わせる。「px」とかのわけのわからない一文字化略記が今時の「読みやすい」？笑う。ちゃんと略さないで書けっての。
Re:いや、存じてるでしょ (スコア:1)
と、いうことは、略されてさえいないのであれば、prefix はアリだと言うこと? column か row かの区別も型を設けて対応すべきという議論があったけれども、 prefix が「column」「row」と略されずに記されれば文句はないと言うこと?
むらちより/あい/をこめて。
Re:いや、存じてるでしょ (スコア:1)
御意。個人的には、その名前が用いられる文脈上において十分に意味の通る名前であるならば、それで十分だと思っております。
むらちより/あい/をこめて。
Re: (スコア:0)
その文脈をより小さく短く頑強にするためのものがハンガリアン記法などです。
だから、あなたがたの主張は本末転倒なんですよ。
そもそもハンガリアン記法は他の手法と排他的なものではありません。場面に応じて適宜使うべき物です。
これかあれか、という視野の狭さが本末転倒を生んでいるように思えます。
(システムハンガリアンの悪影響でしょうかね)
Re: (スコア:0)
Re: (スコア:0)
今時、短くする必要なんてないし、前置記法にする必然性もない。
20年前の方法をいまだに引きずってる馬鹿がいつまでも強情な言い訳をし続けているようにしか見えない。
Re: (スコア:0)
別に無理して長くする必要もない。意味がわかればそれでいい。
前置記法で短く、わかりやすくすることはできるし、わかりやすいならそれは有用なことだし、短くてわかりやすくなるものをあえて使わない必然性はない。
kgWater, klWater, klpsWater, kgcmWaterPress
それぞれ、水量(kg), 水量(kl), 流水量(kl/s), 水圧(kg/cm2)な。
型を記述するシステムハンガリアンはコンパイラに任せてもいいけど、コンパイラは識別子の意味をチェックしてはくれない。
アプリケーションハンガリアンでやれば済むところを、いちいち型定義してコンパイラに無理矢理やらせようなんて、方向を間違ってる。
Re: (スコア:0)
コンパイラ以外にチェックするものをお持ちでないのですか?
いったい、いつまで紙に鉛筆で書くようなレベルでコーディングしているんですか。
Re: (スコア:0)
意味を記述するところを、型定義で代用しようとする方向性が間違いだと言ってるんです。
意味ごとに型を作って、型変換メソッドを起こしてまで機械にチェックさせるのはコストの無駄。
意味をチェックしてくれる機械が地上に存在するというなら、示してみなさい。
Re:いや、存じてるでしょ (スコア:1)
別に prefix でも postfix でもどっちでもいいよ。名前にそれを含めることを「必要」と考えるか「あった方がいい」という程度に捉えるか、別の手段を採ってでも「不要」とすべきと考えるか、という話。そんだけのことのためにわざわざ型を宣言するのが理想というのはまさに「別の手段を採ってでも「不要」とすべき」という考え方な訳でしょ。
むらちより/あい/をこめて。
Re: (スコア:0)
> kgWater, klWater, klpsWater, kgcmWaterPress
> それぞれ、水量(kg), 水量(kl), 流水量(kl/s), 水圧(kg/cm2)な。
これらは型です。
Re:いや、存じてるでしょ (スコア:1)
だからどっちも極端なんだってば (^_^; 。
型定義もあんまり数多くなりすぎればやっぱりめんどくさいし、細かくやり過ぎればかえってメンテナンス性が落ちる (引き継いでソース管理することになった人が設計を理解しきれなくなる) ということも十分あり得る訳。
そしてそれは「ハンガリアン記法」に代表されるような業務単位での「お約束事」でも同じこと。略記的前置詞は外から引き継ぎ要員連れてきたらそれまた全部覚えさせなきゃならない。MS が「狭義の」ハンガリアン記法を定義したのだって、会社単位・業務単位で記法がばらばらになってしまったら保守コストが上がることを理解していたからだ。でもそんなもん統一できるのなんてそれこそ組み込みの型名とスコープぐらいのものでしかなかった。
大体元よりコピペどころか近頃のエディタは名前の補完機能も優れていてめちゃめちゃ便利になってきているって言うのに、今更長い名前を使うのが面倒くさいなんてこともないでしょうが。最初の 2, 3文字打ち込んで、あとは補完候補を選んであげれば済む。それでソースはさくさく入力できてしまう。それの何が不便だというのか?
むらちより/あい/をこめて。
Re: (スコア:0)
しかし、入力された後の識別子は、何度も何度も繰り返し人間によって読まれます。
寿限無は極端だとしても、長すぎる識別子は読みにくいですから、頻出のものは短縮すべきです。
Re:いや、存じてるでしょ (スコア:1)
それはごもっとも。しかし、それを解決するための手法として、「ハンガリアン記法」と呼ばれる (あるいは揶揄される) やり方が適切であると言えるのか。問題が「長ったらしい」ことではなくて、「煩わしい」ことであるならば、それはむしろローカルルールの略記法では悪化してしまうのでは?
名前の意味の保持を重要視するのであれば、あとは名前空間の活用という手段もあります。クラスや関数を定義し、その中に文脈を閉じ込めるという手段もあります。質量と体積がごっちゃになるのが困るのであれば、質量しか扱わないクラス、体積しか扱わないクラスを定義し、文脈を分けることが可能であるかどうかを検討してみてもいい。もちろん、そうそう分断が容易ではないケースが少なからずあるからこそ、こういうことを問題にしているのであろうかとは思いますが。
むらちより/あい/をこめて。
Re: (スコア:0)
Re: (スコア:0)
P A;
Re: (スコア:0)
> P A;
ほらね、型でOK派はやっぱり何もわかっていない馬鹿なんだよ。
Re: (スコア:0)
ああ、あなたの指す「型」の範囲が、型OKな人の指す「型」の範囲より随分狭いのが
議論の噛み合わない原因なんですね。
という風に見えるけど、違うのかしら。
# 型でOK派(正確には型だけでOK派)なんて、登場していないようにも見えるんだけど…
Re: (スコア:0)
違います。
ヒントを述べますと、型は形式だということです。とはいえそれだけでは馬鹿呼ばわりはしませんが。
> # 型でOK派(正確には型だけでOK派)なんて、登場していないようにも見えるんだけど…
馬鹿なのは何をおいてもこの人で、
(#1560296)
> 型でOK
> P A;
「派」と書いたのは、おそらく他にも同じく無理解の人がいるだろうからです。(私の感触ではほぼ間違いなくいますが、ひょっとしたら一人一派かもしれません)
Re: (スコア:0)
本当に馬鹿ですね。
Re: (スコア:0)
まず前提となる考え方として、
・機械にできることは機械にやらせる、人間にやらせない。
・銀の弾丸を求めない。地道なバグ対策を積み重ねる。
・バグ対策は、工程のできるだけ早い段階で行う。
ということが、あると思います。
アプリケーション・ハンガリアンを使うことで、コードを書く時点でのミスを減らせます。
型(クラス)を適切に使うことで、コンパイル時点でミスを検出できる可能性を高められます。
どちらか一方だけではなく、両方やったほうが、テスト工程に渡されるコードに含まれるミスは減ります。
いちいち型を分けて正しい演算の組み合わせを定義するのは面倒だというのは、馴れていないからでしょう。
あるいは、ツールによる支援を受けられないからでしょう。
Re: (スコア:0)
ハンガリアンはコードの可読性を高めるもの以外の何ものでもありません。
もしコードを書く時点でのミスが減らせたとしたら、それは可読性が高まった結果にすぎません。
> いちいち型を分けて正しい演算の組み合わせを定義するのは面倒だというのは、馴れていないからでしょう。
> あるいは、ツールによる支援を受けられないからでしょう。
前のコメントにも書きましたが、型は形式にすぎず、ハンガリアンとは本質的に異なります。
Re: (スコア:0)
> ハンガリアンはコードの可読性を高めるもの以外の何ものでもありません。
> もしコードを書く時点でのミスが減らせたとしたら、それは可読性が高まった結果にすぎません。
補足説明ありがとうね。
そういうしくみによってコードを書く時点でのミスが減らせるって意図で書いたのよ。
> 前のコメントにも書きましたが、型は形式にすぎず、ハンガリアンとは本質的に異なります。
あなたの言うハンガリアンと、私の言うハンガリアンは違うのかもしれませんね。
ハンガリアン記法を編み出した人は、ハンガリアンが示すのはtypeと言っています。
typeといってもC言語のtypeではなく、D言語のtypeのような意味で、typeと。
Re: (スコア:0)
そうですね。
そしてあなたのような人がシステムハンガリアンを生み出したわけですが。
Re:いや、存じてるでしょ (スコア:1)
職業プログラマでない私が言うのもなんですが、基本的に貴殿の意見に同意します。目的は関係者にとって扱いやすい名前をつけることであり、型や意味を明示することは目的ではなく、手段です。ハンガリアン記法は手段の1つであり、常に万能であるわけではありません。1つのローカルにある変数が数個しかないのに、それにハンガリアン記法を使うのは馬鹿げています。一方、数十個の変数を1つのローカルで定義しないといけないのであれば、アプリケーションハンガリアン記法は有効でしょう。
その辺の事情はプログラミング言語やスタイルによって変わってきます。手続き型のスタイルであれば、ローカル内で定義する変数が多くなるので、アプリケーションハンガリアン記法が必要になるでしょう。一方、関数型やオブジェクト指向のスタイルであれば、関数やクラス内の変数が減るので、アプリケーションハンガリアン記法は冗長になるだけです。
私の場合、最近はSchemeとExcelのマクロ、過去にはJavaとObjective-Cを使っていましたが、アプリケーションハンガリアン記法を使うのはExcelのマクロの場合だけです。他の言語の場合、便利なクラスが既にあったり、クラスや関数を定義するので、ローカルで定義しないといけない変数が少なく、略語や1つの単語で命名してコメントを書き加えておく方が、後でずっと読みやすいです。
その代わり、関数名やクラス名、定数は冗長にしてあります。これは比較的グローバルに使い回しますし、アプリケーションハンガリアン記法を使わないのは、そのために分類して略語を決めるのが難しく、後で見るときも、意味が分かりにくいからです。引数と戻り値と機能を名前に適切に持ち込むためには冗長になっても仕方のないことです。
最近の事情からすれば、システムハンガリアン記法はおろか、アプリケーションハンガリアン記法でさえ、批判の的になることは不思議なことではない気がします。
以上、趣味のプログラマの感想。
Re: (スコア:0)
<a href="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">間違ったコードは間違って見えるようにする</a>
を読んでから
<a href="http://www.maroontress.com/Hungarian/">間違ったコードはコンパイルできないようにする</a>
を読んでみて、よく考えてみてくださ
Re: (スコア:0)
君も後者？
Re: (スコア:0)
どう見ても「装甲集団の1日あたりの水の補給量」ですよね？これ。
Re: (スコア:0)
> どう見ても「装甲集団の1日あたりの水の補給量」ですよね？これ。
常識のないバカにはハンガリアン記法は猫に小判です。
Re: (スコア:0)
Conclusion Do not use qualifiers when not needed, even if they seem valuable.
Re: (スコア:0)
Re: (スコア:0)
>ひょっとしたら一人一派かもしれません
確かにハンガリアン派は一人しか居ない気がするな。それも何かコンプレックスを抱えたキモいのが。