アプリケーションハンバリアン、はじめて知りました、
でもこれ、単位系の整合性は、実行するまでもなくコンパイルレベルでチェックできるんですね。
テンプレートメタプログラミングなどでコンパイル時点でバグを始末してしまえるような気がします、というかコンパイラに機能として組み込むべき？
たとえば
int Y;
Unit pxkg = px * kg;
Y * pxkg = A * px + X * kg;
のような形にして、単位系があっていなければ、即エラー。
機械的にできるならコードレビューチェック化すべきじゃないと思われます。
ハンガリアン記法とか (スコア:0)
Re: (スコア:3, 参考になる)
char szHogeHoge[64]のようなシステムハンガリアンを使うことについては、僕も大嫌いですが。
Re: (スコア:0, すばらしい洞察)
同意しない。だって、そういう目的なら、それ用の型を準備して使えばいいわけで。
暗黙に決めた名前ルールでどうにかしようなんて馬鹿げてて、型でシステマティックに解決するべきです。Javaのような部類の言語（静的型付言語）ならそれができるよね。
けっきょく、ハンガリアン記法なんてものは、静的に型を明示できない言語で型名を変数名に入れているだけだよね。しかもアドホックに。
Re:ハンガリアン記法とか (スコア:0)
例えば、X座標を保持する変数にはpx、重さを保持する変数にはkgというプリフィックスを付けましょうということです。
そうすれば、pxA + kgX という式は誤りである可能性が非常に高いということが字面だけでわかります。
これは型でどうこうできるものではないのは理解いただけると思います。
(むろん言語のほうでどうにかすべきで、curlではなんとかしていますが)
Re:ハンガリアン記法とか (スコア:1)
そんなコスト高な真似をいちいちやってられないケースが多いので、
アプリケーションハンガリアンは有効である、と。
＃演算子オーバーロードができない言語だと、見た目が美しくないし。
Re: (スコア:0)
Turbo Pascalを使えばいいってことですね。わかります。わかります
いや、存じてるでしょ (スコア: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:いや、存じてるでしょ (スコア:2)
> おけば良い物に人間が煩わされるなんて馬鹿馬鹿しい。
コードレビューを行うときにレビュアーにとって便利なんです。
プログラムというのはあなたとコンパイラだけが読むものではありません。
Re: (スコア:0)
奇天烈な記法に頼らないとレビューできないようなコードを書いている時点でレビューする価値も無いという意識が無いのでしょうか。
コンパイラーに出来る事を人間がわざわざコードレビューでやるのは愚かなことです。
Re: (スコア:0)
> 奇天烈な記法に頼らないとレビューできないようなコードを書いている時点でレビューする価値も無いという意識が無いのでしょうか。
とうとうここまでやってきました。コードの価値だなんて、一体何の話になったのやら。
> コンパイラーに出来る事を人間がわざわざコードレビューでやるのは愚かなことです。
御託はいいから、一度コードレビューというものに参加してみてはいかが？体験しないとわからないことも多いよ。
Re: (スコア:0)
御託はいいから、一度ハンガリアン記法をやめてみたらいかが？頭の悪い人には体験しないとわからないようだから。
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:いや、存じてるでしょ (スコア:1)
職業プログラマでない私が言うのもなんですが、基本的に貴殿の意見に同意します。目的は関係者にとって扱いやすい名前をつけることであり、型や意味を明示することは目的ではなく、手段です。ハンガリアン記法は手段の1つであり、常に万能であるわけではありません。1つのローカルにある変数が数個しかないのに、それにハンガリアン記法を使うのは馬鹿げています。一方、数十個の変数を1つのローカルで定義しないといけないのであれば、アプリケーションハンガリアン記法は有効でしょう。
その辺の事情はプログラミング言語やスタイルによって変わってきます。手続き型のスタイルであれば、ローカル内で定義する変数が多くなるので、アプリケーションハンガリアン記法が必要になるでしょう。一方、関数型やオブジェクト指向のスタイルであれば、関数やクラス内の変数が減るので、アプリケーションハンガリアン記法は冗長になるだけです。
私の場合、最近はSchemeとExcelのマクロ、過去にはJavaとObjective-Cを使っていましたが、アプリケーションハンガリアン記法を使うのはExcelのマクロの場合だけです。他の言語の場合、便利なクラスが既にあったり、クラスや関数を定義するので、ローカルで定義しないといけない変数が少なく、略語や1つの単語で命名してコメントを書き加えておく方が、後でずっと読みやすいです。
その代わり、関数名やクラス名、定数は冗長にしてあります。これは比較的グローバルに使い回しますし、アプリケーションハンガリアン記法を使わないのは、そのために分類して略語を決めるのが難しく、後で見るときも、意味が分かりにくいからです。引数と戻り値と機能を名前に適切に持ち込むためには冗長になっても仕方のないことです。
最近の事情からすれば、システムハンガリアン記法はおろか、アプリケーションハンガリアン記法でさえ、批判の的になることは不思議なことではない気がします。
以上、趣味のプログラマの感想。
Re: (スコア:0)
たとえば表の列番号と行番号を変数に格納するとして、
わざわざそのためにcolumn型とrow型を
用意しろってことですか？ かえって分かりづらくなると思うんですが。
Re: (スコア:0)
int型と命名規約で済むところを、わざわざ型を増やすのは馬鹿臭い。
Re: (スコア:0)
完璧だけど多くの手間が掛かる方法より、抜けがあっても僅かな手間で済む手法の方が開発現場では好まれると思います。
Re: (スコア:0)
長さとか質量とか、物理量の場合には、異なる次元の物理量同士の加減は誤りである可能性が高いですが、
乗除は誤りとは言えません。たとえば、速度を得るには長さを時間で割りますよね。
Re: (スコア:0)
違います。
速度を得るには、距離と時間から速度を計算する関数を呼ぶべきです。
異なる意味の数値どうしの演算をしている箇所を限定することでレビューやテストがやりやすくなるし、
異なる意味の数値どうしの演算や代入を機械的に排除することでバグを発見しやすくなります。
Re: (スコア:0)
とはいえ、なんでもかんでも関数にしたら、そういう計算をしたい箇所の数が猛烈に多い場合には面倒だ。
特にCみたいに関数リテラルとかが書けない言語だと悲惨。
せめてLispくらい「関数」が便利な言語ならばまだいいんだけども。
Lispなら「xを足す関数」から「5を足す関数」を「作る」のは容易だけど、Cとかだと超面倒だ。
LispよりCのほうが、関数の数にたいするコーディングの手間の処理量オーダーが大きい。
(Cのように支援が乏しいと毎回丸々書く羽目になるからO(n)だが、Lispだともっと少ないのだろう)
とはいえ、次元計算の支援機能もまた無いCでは、「関数をあまり書
アプリケーションハンガリアンは組み込まれるべきだとおもった (スコア:0)
でもこれ、単位系の整合性は、実行するまでもなくコンパイルレベルでチェックできるんですね。
テンプレートメタプログラミングなどでコンパイル時点でバグを始末してしまえるような気がします、というかコンパイラに機能として組み込むべき？
たとえば
int Y;
Unit pxkg = px * kg;
Y * pxkg = A * px + X * kg;
のような形にして、単位系があっていなければ、即エラー。
機械的にできるならコードレビューチェック化すべきじゃないと思われます。