アカウント名:
パスワード:
＞X座標を保持する変数にはpx、重さを保持する変数にはkg
用にそれぞれ別の型を宣言してやればいいんですよ。
>そうすれば、pxA + kgX という式は
コンパイラがワーニングかエラー吐いてくれますよ。こんな機械に判定させておけば良い物に人間が煩わされるなんて馬鹿馬鹿しい。
普通ここまでやらないのはパフォーマンスがどうとか使い勝手がどうとかいう話が絡んでくるからで、アプリケーションハンガリアンなんてもんは所詮妥協の産物ってこった。
プログラミングの経験の少ない人は型でなんでも出来ると思いがちなんだけど、例えばpxA + pxB という式は要注意だが、(pxA + pxB) / 2 という式は平均を取っているのでたぶん問題なし、ということを読み取りたいわけ。
ハンガリアンの目的はコードの可読性を高めることにあるので、型とは目的からして違うんだよ。
そういう記法に頼らなくても馬鹿でも見つけられる例はいらないんだ。
机上の空論はいいから「使ってよかったハンガリアン」と誰もが納得するような実例はないの？
＞指摘してくだちいいい
釣りか自覚してないのか迷うなあ。
＞pxA + kgX
は型が違うので足してはいけないって話が
＞pxA + pxB
いつの間にやら同じ型になって全然違う話に。「同じ型だから安全ぽいよ！」と言いたいならそれこそ型でやるべきだし、そもそも変な命名規則を使わずとも変数の名前からそれが読み取れないような名前をつけてる時点で落第なんですよ。
正論をぶつけられると反論できずに相手を学生呼ばわりして逆切れするのは半端な能力しか無い人間によくある悪い癖ですね。
アホな仕事相手を巧く処理できず、さりとて仕事相手を選ぶ事も出来ない境遇には同情します。
日本語でおk
> X座標クラスオブジェクト同士の加算を定義しなければいい。平均が欲しければ、average(pxA,pxB)を呼ばせる。
あなたが実際に「大規模プログラム開発」の現場で、こんな馬鹿げたことを実行しているというのなら、私の言えることは唯一つです。
嘘つき！
> 「レビューする人が楽するためには、アプリケーションハンガリアンより、クラスは細かく定義して適切に演算子やメソッドを定義する方が有効」というのは真理でしょう。
これはある程度は正しいでしょう。あなたが間違っているのは、ハンガリアンは型システムと排他的なものではないこと（つまり「より」という
>必要なところだけで用いればいい
ハンガリアンに限らずどんな方法論でも「必要なところだけで用いればいい」とは言えるし、「そんな判断をいつ誰が的確にやるんだ？それが出来そうもないから※ルール化するんだろ」と一律義務化したがる勢力との争いになる、ってのも方法論を問わず起きる現象だから、それもまた「だからなに？」でしかないですよ。
※ほんとにそうなのか、それとも人員の能力を把握し損ねてる(つまり実は出来るんだけど)だけなのか、はたまた裁量者のほうが無能で判断できてないだけなのか、もまた場合によりける。
>「識別子は他の名前に変更してもプログラムの意味は変わらない」という事実に基づく
ちょっと待て。それは「冗長」という概念をなにか勘違いした説明だぞ？二人とも勘違いしてるのか、それとも一方だけなのか、は追求しないが。
識別子がそういう意味で冗長だというなら、ためしに、A,Bという二つの変数が有る場面において、BをAにリネームしてみるといい。プログラムは瓦解する(=意味がかわる)から。
>「冗長さは人間にとって役に立つ」
ちょっと違う。人間に読み易いものは人間にとって役立つ、だ。それが冗長であるかどうかとは直接は関係ない。
通し番号的とかランダム的なやりかたで生成した、かつ「冗長さを含んだ」識別子を沢山作った場合、読み易くなるかというとそんなこたぁない。冗長だけど人間に読みにくいものなんて、いくらでも作れる。
てか、なんの話をしてるんだ…？
> X座標クラスオブジェクト同士の加算を定義しなければいい。平均が欲しければ、average(pxA,pxB)を呼ばせる。 あなたが実際に「大規模プログラム開発」の現場で、こんな馬鹿げたことを実行しているというのなら、私の言えることは唯一つです。嘘つき！
あなたが実際に「大規模プログラム開発」の現場で、こんな馬鹿げたことを実行しているというのなら、私の言えることは唯一つです。嘘つき！
まあ、そりゃそうだよね。「大規模プログラム開発（笑）」では、関数を定義したらたとえ中身が1行でも、関数定義修正追加申請書を1枚書いて責任者の承認を得ないといけないですから（笑）。それをさぼってアドホックに対処するためののハンガリアンでしょ（笑）。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
ハンガリアン記法とか (スコア: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, すばらしい洞察)
プログラミングの経験の少ない人は型でなんでも出来ると思いがちなんだけど、例えば
pxA + pxB という式は要注意だが、
(pxA + pxB) / 2 という式は平均を取っているのでたぶん問題なし、
ということを読み取りたいわけ。
ハンガリアンの目的はコードの可読性を高めることにあるので、型とは目的からして違うんだよ。
Re: (スコア:0)
Re: (スコア:0)
そういう記法に頼らなくても馬鹿でも見つけられる例はいらないんだ。
机上の空論はいいから「使ってよかったハンガリアン」と誰もが納得するような実例はないの？
Re:いや、存じてるでしょ (スコア:1, 興味深い)
何にせよ後から書いたほうがより正確ですので、そちらを参照してください。
Re: (スコア:0)
＞指摘してくだちいいい
釣りか自覚してないのか迷うなあ。
＞pxA + kgX
は型が違うので足してはいけないって話が
＞pxA + pxB
いつの間にやら同じ型になって全然違う話に。「同じ型だから安全ぽいよ！」と言いたいならそれこそ型でやるべきだし、そもそも変な命名規則を使わずとも変数の名前からそれが読み取れないような名前をつけてる時点で落第なんですよ。
Re: (スコア:0)
つまり
(pxA + pxB) / 2 という式なら、これは二つの値の平均を取っているわけだから、この部分だけ見てもおそらく正しいことが読み取れる。
これが、単に
pxA + pxB という式だった場合には、バグの可能性があるので要注意、この周りのコードにも気をつけましょうということが分かる。
しかし必ずしも間違ったプログラム片とは限らないので、コンパイラに排除させるわけにはいかない。
> そもそも変な命名規則を使わずとも変数の名前からそれが読み取れないような名前をつけてる時点で落第なんですよ。
学生さんかな？本当にチームプログラミングをやったことがないんだろうね。
俺たちは仕事でプログラムを書いてるわけ。意思疎通がうまく行かなかった場合に、俺は悪くない、悪いのは君だ、君は落第！じゃすまないのね。
Re: (スコア:0)
Cなら、操作を関数として分離しますし、C++ならクラスにしますが演算子や型変換は潰します。
Re: (スコア:0)
正論をぶつけられると反論できずに相手を学生呼ばわりして逆切れするのは半端な能力しか無い人間によくある悪い癖ですね。
アホな仕事相手を巧く処理できず、さりとて仕事相手を選ぶ事も出来ない境遇には同情します。
Re: (スコア:0)
(職業プログラマの経験がないことを否定もしてませんし、嘘をつかないだけの倫理性があるので安心しました)
「型は次元や有向ベクトルと位置ベクトルの区別を扱えない」という私の説明に、あなたは何の反論もできていません。
(私が例を挙げて説明していますので、あなたも俺様の主張だけでなく、例を挙げて説明する必要があります)
あなたがせいぜいしていることは「ハンガリアン記法はごちゃごちゃしている(=ので馬鹿が使う記法だ)」という主張だけです。
ハンガリアン記法が冗長であることは否定しえない事実です。が、あなたの主張する「識別子は意味に応じた名前」もまぎれもなく冗長なものです。
これは「識別子は他の名前に変更してもプログラムの意味は変わらない」という事実に基づくものですから、否定のしようはありません。重要なことは「冗長さは人間にとって役に立つ」ということです。
Re: (スコア:0)
日本語でおk
Re: (スコア:0)
Re: (スコア:0)
そういう人が書いたときに、きちんとアプリケーションハンガリアンのプリフィックスのルールを守っていると信じられるわけもなし、守っているかどうかの不毛なチェックもしたくないし。
＞有向ベクトルと位置ベクトル
それぞれ別のクラスとして定義すればいいだけです。
Re: (スコア:0)
> X座標クラスオブジェクト同士の加算を定義しなければいい。平均が欲しければ、average(pxA,pxB)を呼ばせる。
あなたが実際に「大規模プログラム開発」の現場で、こんな馬鹿げたことを実行しているというのなら、私の言えることは唯一つです。
嘘つき！
> 「レビューする人が楽するためには、アプリケーションハンガリアンより、クラスは細かく定義して適切に演算子やメソッドを定義する方が有効」というのは真理でしょう。
これはある程度は正しいでしょう。
あなたが間違っているのは、ハンガリアンは型システムと排他的なものではないこと（つまり「より」という
Re: (スコア:0)
>必要なところだけで用いればいい
ハンガリアンに限らずどんな方法論でも「必要なところだけで用いればいい」とは言えるし、
「そんな判断をいつ誰が的確にやるんだ？それが出来そうもないから※ルール化するんだろ」
と一律義務化したがる勢力との争いになる、ってのも方法論を問わず起きる現象だから、
それもまた「だからなに？」でしかないですよ。
※ほんとにそうなのか、それとも人員の能力を把握し損ねてる(つまり実は出来るんだけど)だけなのか、はたまた裁量者のほうが無能で判断できてないだけなのか、もまた場合によりける。
Re: (スコア:0)
>「識別子は他の名前に変更してもプログラムの意味は変わらない」という事実に基づく
ちょっと待て。それは「冗長」という概念をなにか勘違いした説明だぞ？
二人とも勘違いしてるのか、それとも一方だけなのか、は追求しないが。
識別子がそういう意味で冗長だというなら、ためしに、
A,B
という二つの変数が有る場面において、
BをAにリネーム
してみるといい。プログラムは瓦解する(=意味がかわる)から。
>「冗長さは人間にとって役に立つ」
ちょっと違う。人間に読み易いものは人間にとって役立つ、だ。
それが冗長であるかどうかとは直接は関係ない。
通し番号的とかランダム的なやりかたで生成した、かつ「冗長さを含んだ」識別子を
沢山作った場合、読み易くなるかというとそんなこたぁない。
冗長だけど人間に読みにくいものなんて、いくらでも作れる。
てか、なんの話をしてるんだ…？
Re: (スコア:0)
> という二つの変数が有る場面において、
> BをAにリネーム
それでは識別子の体をなしていませんが。
> それが冗長であるかどうかとは直接は関係ない。
「好きな識別子名を選べる」ことがすなわち冗長さです。
この冗長さを用いて、人間にとってわかりやすい名前をつけるわけです。
変数名が登場順にa,b,c...と固定されていてプログラマは選べない言語を考えてみるとわかるかと思います。
(数学なんかは似た感じですね)
Re: (スコア:0)
Re: (スコア:0)
まあ、そりゃそうだよね。「大規模プログラム開発（笑）」では、関数を定義したらたとえ中身が1行でも、関数定義修正追加申請書を1枚書いて責任者の承認を得ないといけないですから（笑）。それをさぼってアドホックに対処するためののハンガリアンでしょ（笑）。
Re: (スコア:0)
実行してるわけ無いでしょ。理由は、主として、↓こう書いたとおり。
＞問題は、処理効率もありますが、そんな難しいことを考えられる人が100人のプログラマの中に1人もいないこと。
もちろん、↓お金と期間もです。すまん。期間のことを書き漏れた。
＞「目の前の問題を今あるお金と今いる人でやっつけることの困難さ」の話は交わりません。
で、そういう話はさておいて、
＞「こういう問題はこうすれば解決する」という議論