パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

もうやらなくていい昔のコーディングテクニックあれこれ」記事へのコメント

  • あれを未だにやめず使う人の気が知れんです。
    • Re: (スコア:3, 参考になる)

      アプリケーションハンガリアン [joelonsoftware.com]は結構有効な気はします。
      char szHogeHoge[64]のようなシステムハンガリアンを使うことについては、僕も大嫌いですが。
      • Re: (スコア:0, すばらしい洞察)

        by Anonymous Coward
        > アプリケーションハンガリアンは結構有効な気はします。

        同意しない。だって、そういう目的なら、それ用の型を準備して使えばいいわけで。
        暗黙に決めた名前ルールでどうにかしようなんて馬鹿げてて、型でシステマティックに解決するべきです。Javaのような部類の言語(静的型付言語)ならそれができるよね。

        けっきょく、ハンガリアン記法なんてものは、静的に型を明示できない言語で型名を変数名に入れているだけだよね。しかもアドホックに。
        • by Anonymous Coward
          アプリケーションハンガリアンをご存知ないようですので軽く説明しておきますと、
          例えば、X座標を保持する変数にはpx、重さを保持する変数にはkgというプリフィックスを付けましょうということです。
          そうすれば、pxA + kgX という式は誤りである可能性が非常に高いということが字面だけでわかります。

          これは型でどうこうできるものではないのは理解いただけると思います。
          (むろん言語のほうでどうにかすべきで、curlではなんとかしていますが)
          • by Anonymous Coward on 2009年05月04日 17時38分 (#1559109)

            >X座標を保持する変数にはpx、重さを保持する変数にはkg

            用にそれぞれ別の型を宣言してやればいいんですよ。

            >そうすれば、pxA + kgX という式は

            コンパイラがワーニングかエラー吐いてくれますよ。こんな機械に判定させておけば良い物に人間が煩わされるなんて馬鹿馬鹿しい。

            普通ここまでやらないのはパフォーマンスがどうとか使い勝手がどうとかいう話が絡んでくるからで、アプリケーションハンガリアンなんてもんは所詮妥協の産物ってこった。

            親コメント
            • by Anonymous Coward on 2009年05月04日 18時03分 (#1559125)

              プログラミングの経験の少ない人は型でなんでも出来ると思いがちなんだけど、例えば
              pxA + pxB という式は要注意だが、
              (pxA + pxB) / 2 という式は平均を取っているのでたぶん問題なし、
              ということを読み取りたいわけ。

              ハンガリアンの目的はコードの可読性を高めることにあるので、型とは目的からして違うんだよ。

              親コメント
              • by Anonymous Coward
                いつの間にか例と話が摩り替わってるね。
              • by Anonymous Coward

                そういう記法に頼らなくても馬鹿でも見つけられる例はいらないんだ。

                机上の空論はいいから「使ってよかったハンガリアン」と誰もが納得するような実例はないの?

              • by Anonymous Coward on 2009年05月04日 18時36分 (#1559143)
                難癖つけてるんでなければ、どこがどうすり替わっているのか具体的に指摘してくだちいいい。訂正します。
                何にせよ後から書いたほうがより正確ですので、そちらを参照してください。
                親コメント
              • by Anonymous Coward

                >指摘してくだちいいい

                釣りか自覚してないのか迷うなあ。

                >pxA + kgX

                は型が違うので足してはいけないって話が

                >pxA + pxB

                いつの間にやら同じ型になって全然違う話に。「同じ型だから安全ぽいよ!」と言いたいならそれこそ型でやるべきだし、そもそも変な命名規則を使わずとも変数の名前からそれが読み取れないような名前をつけてる時点で落第なんですよ。

              • by Anonymous Coward
                ああ、例が悪かったかな。後者の例のほうがより適切です。
                つまり

                (pxA + pxB) / 2 という式なら、これは二つの値の平均を取っているわけだから、この部分だけ見てもおそらく正しいことが読み取れる。
                これが、単に

                pxA + pxB という式だった場合には、バグの可能性があるので要注意、この周りのコードにも気をつけましょうということが分かる。
                しかし必ずしも間違ったプログラム片とは限らないので、コンパイラに排除させるわけにはいかない。

                > そもそも変な命名規則を使わずとも変数の名前からそれが読み取れないような名前をつけてる時点で落第なんですよ。

                学生さんかな?本当にチームプログラミングをやったことがないんだろうね。
                俺たちは仕事でプログラムを書いてるわけ。意思疎通がうまく行かなかった場合に、俺は悪くない、悪いのは君だ、君は落第!じゃすまないのね。
              • by Anonymous Coward
                そもそも、何らかの意図をもった処理を、どんなに短くても、その場にベタベタと書くべきではないと思う。
                Cなら、操作を関数として分離しますし、C++ならクラスにしますが演算子や型変換は潰します。
              • by Anonymous Coward

                正論をぶつけられると反論できずに相手を学生呼ばわりして逆切れするのは半端な能力しか無い人間によくある悪い癖ですね。

                アホな仕事相手を巧く処理できず、さりとて仕事相手を選ぶ事も出来ない境遇には同情します。

              • by Anonymous Coward
                よっぽど気に障ったようですが、学生さんには学生さんには何かあるのでしょうか。
                (職業プログラマの経験がないことを否定もしてませんし、嘘をつかないだけの倫理性があるので安心しました)

                「型は次元や有向ベクトルと位置ベクトルの区別を扱えない」という私の説明に、あなたは何の反論もできていません。
                (私が例を挙げて説明していますので、あなたも俺様の主張だけでなく、例を挙げて説明する必要があります)
                あなたがせいぜいしていることは「ハンガリアン記法はごちゃごちゃしている(=ので馬鹿が使う記法だ)」という主張だけです。

                ハンガリアン記法が冗長であることは否定しえない事実です。が、あなたの主張する「識別子は意味に応じた名前」もまぎれもなく冗長なものです。
                これは「識別子は他の名前に変更してもプログラムの意味は変わらない」という事実に基づくものですから、否定のしようはありません。重要なことは「冗長さは人間にとって役に立つ」ということです。
              • by Anonymous Coward

                日本語でおk

              • by Anonymous Coward
                あなたでもわかりそうな日本語で説明すると、「あなたはずいぶん幼稚な人ですね」。
              • by Anonymous Coward
                「大規模プログラム開発」の現場では、プログラマが100人いるとして、「ハンガリアン記法とは何か」を説明できる人が50人もいないだろうし、「ハンガリアン記法の長所と短所」を語れれる人が1人か2人いれば御の字なわけで、そういう現場で使われる規約は、頭の働くプログラマの間で使われる規約と大きく異なるわけです。
                そういう人が書いたときに、きちんとアプリケーションハンガリアンのプリフィックスのルールを守っていると信じられるわけもなし、守っているかどうかの不毛なチェックもしたくないし。

                >有向ベクトルと位置ベクトル

                それぞれ別のクラスとして定義すればいいだけです。
              • by Anonymous Coward

                > X座標クラスオブジェクト同士の加算を定義しなければいい。平均が欲しければ、average(pxA,pxB)を呼ばせる。

                あなたが実際に「大規模プログラム開発」の現場で、こんな馬鹿げたことを実行しているというのなら、私の言えることは唯一つです。

                嘘つき!

                > 「レビューする人が楽するためには、アプリケーションハンガリアンより、クラスは細かく定義して適切に演算子やメソッドを定義する方が有効」というのは真理でしょう。

                これはある程度は正しいでしょう。
                あなたが間違っているのは、ハンガリアンは型システムと排他的なものではないこと(つまり「より」という

              • by Anonymous Coward

                >必要なところだけで用いればいい

                ハンガリアンに限らずどんな方法論でも「必要なところだけで用いればいい」とは言えるし、
                「そんな判断をいつ誰が的確にやるんだ?それが出来そうもないから※ルール化するんだろ」
                と一律義務化したがる勢力との争いになる、ってのも方法論を問わず起きる現象だから、
                それもまた「だからなに?」でしかないですよ。

                ※ほんとにそうなのか、それとも人員の能力を把握し損ねてる(つまり実は出来るんだけど)だけなのか、はたまた裁量者のほうが無能で判断できてないだけなのか、もまた場合によりける。

              • by Anonymous Coward

                >「識別子は他の名前に変更してもプログラムの意味は変わらない」という事実に基づく

                ちょっと待て。それは「冗長」という概念をなにか勘違いした説明だぞ?
                二人とも勘違いしてるのか、それとも一方だけなのか、は追求しないが。

                識別子がそういう意味で冗長だというなら、ためしに、
                A,B
                という二つの変数が有る場面において、
                BをAにリネーム
                してみるといい。プログラムは瓦解する(=意味がかわる)から。

                >「冗長さは人間にとって役に立つ」

                ちょっと違う。人間に読み易いものは人間にとって役立つ、だ。
                それが冗長であるかどうかとは直接は関係ない。

                通し番号的とかランダム的なやりかたで生成した、かつ「冗長さを含んだ」識別子を
                沢山作った場合、読み易くなるかというとそんなこたぁない。
                冗長だけど人間に読みにくいものなんて、いくらでも作れる。

                てか、なんの話をしてるんだ…?

              • by Anonymous Coward
                > A,B
                > という二つの変数が有る場面において、
                > BをAにリネーム

                それでは識別子の体をなしていませんが。

                > それが冗長であるかどうかとは直接は関係ない。

                「好きな識別子名を選べる」ことがすなわち冗長さです。
                この冗長さを用いて、人間にとってわかりやすい名前をつけるわけです。

                変数名が登場順にa,b,c...と固定されていてプログラマは選べない言語を考えてみるとわかるかと思います。
                (数学なんかは似た感じですね)
              • by Anonymous Coward
                わざと変な方向に誤解し、その誤解に対して批判を加えるとは、いったいどんな自虐プレイ?
              • by Anonymous Coward

                > X座標クラスオブジェクト同士の加算を定義しなければいい。平均が欲しければ、average(pxA,pxB)を呼ばせる。

                あなたが実際に「大規模プログラム開発」の現場で、こんな馬鹿げたことを実行しているというのなら、私の言えることは唯一つです。嘘つき!

                まあ、そりゃそうだよね。「大規模プログラム開発(笑)」では、関数を定義したらたとえ中身が1行でも、関数定義修正追加申請書を1枚書いて責任者の承認を得ないといけないですから(笑)。それをさぼってアドホックに対処するためののハンガリアンでしょ(笑)。

            • > コンパイラがワーニングかエラー吐いてくれますよ。こんな機械に判定させて
              > おけば良い物に人間が煩わされるなんて馬鹿馬鹿しい。

              コードレビューを行うときにレビュアーにとって便利なんです。

              プログラムというのはあなたとコンパイラだけが読むものではありません。
              親コメント
              • by Anonymous Coward

                奇天烈な記法に頼らないとレビューできないようなコードを書いている時点でレビューする価値も無いという意識が無いのでしょうか。

                コンパイラーに出来る事を人間がわざわざコードレビューでやるのは愚かなことです。

              • by Anonymous Coward
                ハンガリアン記法はコード可読性を高めるのでレビューに有用、という話が

                > 奇天烈な記法に頼らないとレビューできないようなコードを書いている時点でレビューする価値も無いという意識が無いのでしょうか。

                とうとうここまでやってきました。コードの価値だなんて、一体何の話になったのやら。

                > コンパイラーに出来る事を人間がわざわざコードレビューでやるのは愚かなことです。

                御託はいいから、一度コードレビューというものに参加してみてはいかが?体験しないとわからないことも多いよ。
              • by Anonymous Coward
                コード可読性を高めるなら、型を使えばいいのであって、ハンガリアン記法なんて無用かつ不完全、という話が、とうとうここまでやってきました。

                御託はいいから、一度ハンガリアン記法をやめてみたらいかが?頭の悪い人には体験しないとわからないようだから。
            • 普通ここまでやらないのはパフォーマンスがどうとか使い勝手がどうとかいう話が絡んでくるからで、アプリケーションハンガリアンなんてもんは所詮妥協の産物ってこった。

              おっしゃる通りで、どっちに寄りかかるにせよ、狂信的な原理主義者に現場が振り回されるのだけは勘弁して欲しいものです。

              しかしこの辺の議論を読んでいて思ったのですが、最近のトレンドではハンガリアンという代名詞を持ち出すまでもなく、変数や関数に「意味のある名称」をつけること自体、もはや時代遅れとされつつあるのでしょうか? 元々ハンガリアン記法が忌み嫌われていた一番の理由は、処理系の都合に過ぎない (組み込みの) 型という概念の為だけに名前付けが冗長になってしまうことであり、それは名前に対するセマンティクスの重視と、読みやすくメンテナンスしやすいプログラムソースの追求という命題に対する裏返しなのだと思っていたのですが。

              --
              むらちより/あい/をこめて。
              親コメント
              • by Anonymous Coward

                >変数や関数に「意味のある名称」をつけること自体、もはや時代遅れとされつつあるのでしょうか?

                そんな極端な。

                ハンガリアンは複数の意味を無闇やたらにオーバーロードした結果、意味が通りにくくなって本末転倒だから嫌われてるだけだと思いますが。

                コンパイラの型チェックに頼らなくても、今時はドキュメント自動生成方法が充実していたりIntellisenseのような手段も一般的になって人間が変な手間をかけなくても機械の方がなんとかしてくれるってことだけだと思います。

              • by Anonymous Coward

                ハンガリアン記法が(snip)それは名前に対するセマンティクスの重視と、読みやすくメンテナンスしやすいプログラムソースの追求という命題に対する裏返しなのだと思っていたのですが。

                笑わせる。「px」とかのわけのわからない一文字化略記が今時の「読みやすい」?笑う。ちゃんと略さないで書けっての。

              • と、いうことは、略されてさえいないのであれば、prefix はアリだと言うこと? column か row かの区別も型を設けて対応すべきという議論があったけれども、 prefix が「column」「row」と略されずに記されれば文句はないと言うこと?

                --
                むらちより/あい/をこめて。
                親コメント
              • 御意。個人的には、その名前が用いられる文脈上において十分に意味の通る名前であるならば、それで十分だと思っております。

                --
                むらちより/あい/をこめて。
                親コメント
              • by Anonymous Coward
                > 御意。個人的には、その名前が用いられる文脈上において十分に意味の通る名前であるならば、それで十分だと思っております。

                その文脈をより小さく短く頑強にするためのものがハンガリアン記法などです。
                だから、あなたがたの主張は本末転倒なんですよ。

                そもそもハンガリアン記法は他の手法と排他的なものではありません。場面に応じて適宜使うべき物です。
                これかあれか、という視野の狭さが本末転倒を生んでいるように思えます。
                (システムハンガリアンの悪影響でしょうかね)
              • by Anonymous Coward
                なんで prefix(前置詞)にする必要があるの?と。普通に他の識別子同様に正しい文章のならびにすればいいだけのこと。
              • by Anonymous Coward
                > その文脈をより小さく短く頑強にするためのものがハンガリアン記法などです。

                今時、短くする必要なんてないし、前置記法にする必然性もない。

                20年前の方法をいまだに引きずってる馬鹿がいつまでも強情な言い訳をし続けているようにしか見えない。
              • by Anonymous Coward

                今時、短くする必要なんてないし、前置記法にする必然性もない。

                別に無理して長くする必要もない。意味がわかればそれでいい。
                前置記法で短く、わかりやすくすることはできるし、わかりやすいならそれは有用なことだし、短くてわかりやすくなるものをあえて使わない必然性はない。
                kgWater, klWater, klpsWater, kgcmWaterPress
                それぞれ、水量(kg), 水量(kl), 流水量(kl/s), 水圧(kg/cm2)な。

                型を記述するシステムハンガリアンはコンパイラに任せてもいいけど、コンパイラは識別子の意味をチェックしてはくれない。
                アプリケーションハンガリアンでやれば済むところを、いちいち型定義してコンパイラに無理矢理やらせようなんて、方向を間違ってる。

              • by Anonymous Coward
                型定義、そんなに大変ですか?
                コンパイラ以外にチェックするものをお持ちでないのですか?

                いったい、いつまで紙に鉛筆で書くようなレベルでコーディングしているんですか。
              • by Anonymous Coward

                意味を記述するところを、型定義で代用しようとする方向性が間違いだと言ってるんです。
                意味ごとに型を作って、型変換メソッドを起こしてまで機械にチェックさせるのはコストの無駄。

                コンパイラ以外にチェックするものをお持ちでないのですか?

                意味をチェックしてくれる機械が地上に存在するというなら、示してみなさい。

              • 別に prefix でも postfix でもどっちでもいいよ。名前にそれを含めることを「必要」と考えるか「あった方がいい」という程度に捉えるか、別の手段を採ってでも「不要」とすべきと考えるか、という話。そんだけのことのためにわざわざ型を宣言するのが理想というのはまさに「別の手段を採ってでも「不要」とすべき」という考え方な訳でしょ。

                --
                むらちより/あい/をこめて。
                親コメント
              • by Anonymous Coward
                あなたは型という意味で「意味」を使っていますね。

                > kgWater, klWater, klpsWater, kgcmWaterPress
                > それぞれ、水量(kg), 水量(kl), 流水量(kl/s), 水圧(kg/cm2)な。

                これらは型です。
              • だからどっちも極端なんだってば (^_^;

                型定義もあんまり数多くなりすぎればやっぱりめんどくさいし、細かくやり過ぎればかえってメンテナンス性が落ちる (引き継いでソース管理することになった人が設計を理解しきれなくなる) ということも十分あり得る訳。

                そしてそれは「ハンガリアン記法」に代表されるような業務単位での「お約束事」でも同じこと。略記的前置詞は外から引き継ぎ要員連れてきたらそれまた全部覚えさせなきゃならない。MS が「狭義の」ハンガリアン記法を定義したのだって、会社単位・業務単位で記法がばらばらになってしまったら保守コストが上がることを理解していたからだ。でもそんなもん統一できるのなんてそれこそ組み込みの型名とスコープぐらいのものでしかなかった。

                大体元よりコピペどころか近頃のエディタは名前の補完機能も優れていてめちゃめちゃ便利になってきているって言うのに、今更長い名前を使うのが面倒くさいなんてこともないでしょうが。最初の 2, 3文字打ち込んで、あとは補完候補を選んであげれば済む。それでソースはさくさく入力できてしまう。それの何が不便だというのか?

                --
                むらちより/あい/をこめて。
                親コメント
              • by Anonymous Coward
                ソースコードの入力の手間なんてのは、微々たるものです。入力は1度きりですから。
                しかし、入力された後の識別子は、何度も何度も繰り返し人間によって読まれます。
                寿限無は極端だとしても、長すぎる識別子は読みにくいですから、頻出のものは短縮すべきです。
              • それはごもっとも。しかし、それを解決するための手法として、「ハンガリアン記法」と呼ばれる (あるいは揶揄される) やり方が適切であると言えるのか。問題が「長ったらしい」ことではなくて、「煩わしい」ことであるならば、それはむしろローカルルールの略記法では悪化してしまうのでは?

                名前の意味の保持を重要視するのであれば、あとは名前空間の活用という手段もあります。クラスや関数を定義し、その中に文脈を閉じ込めるという手段もあります。質量と体積がごっちゃになるのが困るのであれば、質量しか扱わないクラス、体積しか扱わないクラスを定義し、文脈を分けることが可能であるかどうかを検討してみてもいい。もちろん、そうそう分断が容易ではないケースが少なからずあるからこそ、こういうことを問題にしているのであろうかとは思いますが。

                --
                むらちより/あい/をこめて。
                親コメント
              • by Anonymous Coward
                「述語Pを満たす値を保持する変数A」はハンガリアン記法ではたとえば AcPと書くことができますが、一般的には型では不可能ですね。
              • by Anonymous Coward
                型でOK
                P A;
              • by Anonymous Coward
                > 型でOK
                > P A;

                ほらね、型でOK派はやっぱり何もわかっていない馬鹿なんだよ。
              • by Anonymous Coward
                > ほらね、型でOK派はやっぱり何もわかっていない馬鹿なんだよ。

                ああ、あなたの指す「型」の範囲が、型OKな人の指す「型」の範囲より随分狭いのが
                議論の噛み合わない原因なんですね。

                という風に見えるけど、違うのかしら。

                # 型でOK派(正確には型だけでOK派)なんて、登場していないようにも見えるんだけど…
              • とりあえず、叩きたいだけの人がいるようですので、議論の流れに沿わないのであれば放っておけば良いのではないかと。

                職業プログラマでない私が言うのもなんですが、基本的に貴殿の意見に同意します。目的は関係者にとって扱いやすい名前をつけることであり、型や意味を明示することは目的ではなく、手段です。ハンガリアン記法は手段の1つであり、常に万能であるわけではありません。1つのローカルにある変数が数個しかないのに、それにハンガリアン記法を使うのは馬鹿げています。一方、数十個の変数を1つのローカルで定義しないといけないのであれば、アプリケーションハンガリアン記法は有効でしょう。

                その辺の事情はプログラミング言語やスタイルによって変わってきます。手続き型のスタイルであれば、ローカル内で定義する変数が多くなるので、アプリケーションハンガリアン記法が必要になるでしょう。一方、関数型やオブジェクト指向のスタイルであれば、関数やクラス内の変数が減るので、アプリケーションハンガリアン記法は冗長になるだけです。

                私の場合、最近はSchemeとExcelのマクロ、過去にはJavaとObjective-Cを使っていましたが、アプリケーションハンガリアン記法を使うのはExcelのマクロの場合だけです。他の言語の場合、便利なクラスが既にあったり、クラスや関数を定義するので、ローカルで定義しないといけない変数が少なく、略語や1つの単語で命名してコメントを書き加えておく方が、後でずっと読みやすいです。

                その代わり、関数名やクラス名、定数は冗長にしてあります。これは比較的グローバルに使い回しますし、アプリケーションハンガリアン記法を使わないのは、そのために分類して略語を決めるのが難しく、後で見るときも、意味が分かりにくいからです。引数と戻り値と機能を名前に適切に持ち込むためには冗長になっても仕方のないことです。

                最近の事情からすれば、システムハンガリアン記法はおろか、アプリケーションハンガリアン記法でさえ、批判の的になることは不思議なことではない気がします。

                以上、趣味のプログラマの感想。
                親コメント
            • by Anonymous Coward

              たとえば表の列番号と行番号を変数に格納するとして、
              わざわざそのためにcolumn型とrow型を
              用意しろってことですか? かえって分かりづらくなると思うんですが。

              • by Anonymous Coward

                int型と命名規約で済むところを、わざわざ型を増やすのは馬鹿臭い。

              • by Anonymous Coward
                現在使われている言語で実装する場合、新たな型を定義するよりも命名規則で済ませる方がcost-benefitの面で有利じゃないですかね?
                完璧だけど多くの手間が掛かる方法より、抜けがあっても僅かな手間で済む手法の方が開発現場では好まれると思います。
            • by Anonymous Coward

              長さとか質量とか、物理量の場合には、異なる次元の物理量同士の加減は誤りである可能性が高いですが、
              乗除は誤りとは言えません。たとえば、速度を得るには長さを時間で割りますよね。

              • by Anonymous Coward
                > 速度を得るには長さを時間で割りますよね。

                違います。

                速度を得るには、距離と時間から速度を計算する関数を呼ぶべきです。
                異なる意味の数値どうしの演算をしている箇所を限定することでレビューやテストがやりやすくなるし、
                異なる意味の数値どうしの演算や代入を機械的に排除することでバグを発見しやすくなります。
              • by Anonymous Coward

                とはいえ、なんでもかんでも関数にしたら、そういう計算をしたい箇所の数が猛烈に多い場合には面倒だ。
                特にCみたいに関数リテラルとかが書けない言語だと悲惨。
                せめてLispくらい「関数」が便利な言語ならばまだいいんだけども。

                Lispなら「xを足す関数」から「5を足す関数」を「作る」のは容易だけど、Cとかだと超面倒だ。
                LispよりCのほうが、関数の数にたいするコーディングの手間の処理量オーダーが大きい。
                (Cのように支援が乏しいと毎回丸々書く羽目になるからO(n)だが、Lispだともっと少ないのだろう)

                とはいえ、次元計算の支援機能もまた無いCでは、「関数をあまり書

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

処理中...