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

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

  • あれを未だにやめず使う人の気が知れんです。
    • by A7M (259) on 2009年05月04日 15時42分 (#1559051) ホームページ 日記
      アプリケーションハンガリアン [joelonsoftware.com]は結構有効な気はします。
      char szHogeHoge[64]のようなシステムハンガリアンを使うことについては、僕も大嫌いですが。
      親コメント
      • そうですか? ポインタには、p つけとかないと何となく不安になるんですが。
        親コメント
        • 自分ではやりませんが、人がやっている分にはスルーする事にしています。

          ただ、

          Windows界隈ですが、変数名ではなく型名にハンガリアン記法(っぽい)定義がされているのが、よくあります。

          符号無し32ビット整数である DWORD に対して、それのポインタである LPDWORD が定義されているわけです。
          これだと頭が混乱するので、素直に DWORD * と書いて欲しいわけです。

          ポインタ値を“ポインタ返し”関数があったとします。たとえば以下のようなものです。

          void hoge (void **p);

          これをマイクロソフト流に書くと、

          void hoge (LPVOID *p);

          となります。この辺で、かなりイラっときます。

          文字列ポインタは、マルチバイト文字かワイド文字か、constの有り無しで、以下のように定義されています。

          LPSTR
          LPCSTR
          LPWSTR
          LPCWSTR

          ときどき LPCWSTR * なんてのが出てきます。この辺で、殺意を覚えます。

          素直に、

          char *
          const char *
          wchar_t *
          const wchar_t *

          って書いてくれれば、混乱しなくて済むのに。

          親コメント
          • by Anonymous Coward on 2009年05月04日 20時11分 (#1559180)

            それは、ターゲット環境によって
            typedef const char *LPCSTR;

            typedef const char __far *LPCSTR;
            を定義し分けなければいけなかった時代の名残なのです。今となってはまさに「もうやらなくていいコーディングテクニック」ですね。

            親コメント
          • HANDLE が void* なのか struct { ... } _HANDLE, *HANDLE; なのかとかの違いを再コンパイルだけで通せるようにするためのものですから。
            TCHAR が char なのか wchar_t なのかもコンパイルスイッチ依存で LPTSTR とかを使う場合が多いように思いますけど、そんなに LPSTR とか使いますか?

            # そして printf_s() の呼び出しを軒並み wprintf_s に変えたりすることに。

            親コメント
            • char か wchar_t をコンパイルスイッチで切り替えて、どちらでもコンパイルが通るように保守すること自体が、(今となっては)無理があると思うのです。

              私はデータ型のサイズをいつも意識に入れながらコードを書くので、TCHARがマルチバイト文字なのかワイド文字なのかを“意識せずに”コードを書くのは、私には無理です。なのでT〜系の文字型を使ったことはありません。

              MFCと決別してQtを使い始めてから、T〜系の文字列型は必要なくなったので char か wchar_t を意識して書き分けます。普段のGUIアプリならそれでいいのですが、まれに要件の制約でMFC等を使わざるを得ない場合は、“文字セット=Unicode文字セットを使用する”にして、 wchar_t * を使います。それでも char * が必要なときは FunctionNameA() の用にサフィックス(?)付きで使います。

              そんなわけで、T〜系の文字列型は「もうやらなくていい昔のコーディングテクニック」だと思うです。

              親コメント
        • それがいつまでもポインタである保障が無いことに気がついていませんね. そのデータは現在の実装で, たまたまポインタを使っているにすぎません.

          将来的に例えば整数のidに変わった場合, ソース中の全ての接頭文字をpからiに変えるのですか? それは無駄/バグの元になると思いませんか? 変えないとすれば, 実態と表現の食い違いをゆるすことになり, ルールを根本から否定すると思いませんか?

          親コメント
          • ポインタ変数 → 整数値 なんて大変更を行う場合、
            参照箇所は全修正だから、変数名を変更して未修正の箇所をコンパイラに指摘して貰う方が安全だと思う。

            # 特に、void * を使っている場合、注意が必要。(警告潰しのためにキャストしている馬鹿が多い)
            --
            notice : I ignore an anonymous contribution.
            親コメント
          • by Anonymous Coward
            > 将来的に例えば整数のidに変わった場合

            きっとそれまでにはプログラムが使われなくなるに100カノッサ。

            冗談はこれくらいにして、ポインタという機能の振る舞いを変えなければ、
            それが整数のidに変わったからといってなんら問題は起こらないとはず。

            ポインタという機能の振る舞いを変えてしまうくらい言語仕様が変更に
            なってしまうのなら、これは相当ひどい言語だと思う。その時には
            「こんな言語を選択してしまったことが一番の間違い」といわれるだろう。
            • by Anonymous Coward

              >きっとそれまでにはプログラムが使われなくなるに100カノッサ。

              ・・・2000年問題

          • by Anonymous Coward

            接頭文字をpからiに変えるなら、LPSTRがポインタでなくなる時点でLPを変えなきゃね。

          • by Anonymous Coward

            >いつまでもポインタである保障が無いこと

            ということは、少なくともJavaとかでハンガリアンする奴の正当性は全く無いってことだな。
            型的にも値的にも「ポインタ(参照)がそうでなくなること」は絶対にないので。

            いや、いるんですよ。JavaだのRubyだのでもハンガリアる奴がorz

            #rubyは変数に型こそないが「全てがポインタ(参照)だ」なのだから結局は同じこと。

          • by Anonymous Coward
            > それがいつまでもポインタである保障が無いことに気がついていませんね.
            >そのデータは現在の実装で, たまたまポインタを使っているにすぎません.

            いやいや、ありないから(笑
            LPDWORD等で利用されているLPはlong pointerの略で
            Microsoft的にハンガリアン記法として利用しているものだから
            未来永劫、ポインタであることに違いはありません。
            これが変更された場合、ハンガリアン記法である意味そのものがなくなってしまいます。

            typedefの結果現在の型が偶然そうなっているだけなんだという、論点は理解できますが
            この議論でたまたまポインタになっているというはあり得ません。
        • by Anonymous Coward
          やめてみると不要だってわかるよ
          間違ったらエラーになるようなケースが大半ですんで、だからそれよりもっと重要な情報を入れたくなる。
      • Re: (スコア:0, すばらしい洞察)

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

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

        けっきょく、ハンガリアン記法なんてものは、静的に型を明示できない言語で型名を変数名に入れているだけだよね。しかもアドホックに。
        • 単にハンガリアンって言う場合は、システムハンガリアンを表すみたいですね。
          http://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%B3%E3%82%AC%E3%83%AA%E3%8... [wikipedia.org]
          システムハンガリアンとアプリケーションハンガリアンの区別がついていない人は、まだまだ多いと思います。
          ハンガリアンを考えついた人は、本当はアプリケーションハンガリアンを意味していたのに、誤解されてしまったようですね。
          親コメント
        • 入力された生の文字列を格納する変数名と、サニタイズ済みの文字列を格納する変数名が一目で判るようになっていれば便利です。
          このようなケースではアプリケーションハンガリアンが簡単で楽です。

          本当は「サニタイズ済みの文字列クラス」を定義し、
          DBまたはhtmlの出力クラスの引数として「サニタイズ済みの文字列クラス」のみを受付可能にするべきなんでしょうけど、
          そんな面倒な構成、誰が面倒見れるか?という問題が…
          --
          notice : I ignore an anonymous contribution.
          親コメント
          • by Anonymous Coward
            > そんな面倒な構成、誰が面倒見れるか?という問題が…

            変数名で一々区別するのも面倒きわまりないうえ、不完全ですが。
        • by Anonymous Coward
          アプリケーションハンガリアンをご存知ないようですので軽く説明しておきますと、
          例えば、X座標を保持する変数にはpx、重さを保持する変数にはkgというプリフィックスを付けましょうということです。
          そうすれば、pxA + kgX という式は誤りである可能性が非常に高いということが字面だけでわかります。

          これは型でどうこうできるものではないのは理解いただけると思います。
          (むろん言語のほうでどうにかすべきで、curlではなんとかしていますが)
          • 型でなんとかならなくもない(重量クラスとか横座標クラスとかを導入すればいい)けど、
            そんなコスト高な真似をいちいちやってられないケースが多いので、
            アプリケーションハンガリアンは有効である、と。
            #演算子オーバーロードができない言語だと、見た目が美しくないし。
            親コメント
            • by Anonymous Coward
              >そんなコスト高な真似をいちいちやってられないケースが多いので、

              Turbo Pascalを使えばいいってことですね。わかります。わかります
          • >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 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

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

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

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

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

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

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

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

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

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

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

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

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

                そんな極端な。

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

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

              • by Anonymous Coward

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

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

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

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

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

                --
                むらちより/あい/をこめて。
                親コメント
              • だからどっちも極端なんだってば (^_^;

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

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

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

                --
                むらちより/あい/をこめて。
                親コメント
              • それはごもっとも。しかし、それを解決するための手法として、「ハンガリアン記法」と呼ばれる (あるいは揶揄される) やり方が適切であると言えるのか。問題が「長ったらしい」ことではなくて、「煩わしい」ことであるならば、それはむしろローカルルールの略記法では悪化してしまうのでは?

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

                --
                むらちより/あい/をこめて。
                親コメント
              • とりあえず、叩きたいだけの人がいるようですので、議論の流れに沿わないのであれば放っておけば良いのではないかと。

                職業プログラマでない私が言うのもなんですが、基本的に貴殿の意見に同意します。目的は関係者にとって扱いやすい名前をつけることであり、型や意味を明示することは目的ではなく、手段です。ハンガリアン記法は手段の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では、「関数をあまり書

          • アプリケーションハンバリアン、はじめて知りました、
            でもこれ、単位系の整合性は、実行するまでもなくコンパイルレベルでチェックできるんですね。
            テンプレートメタプログラミングなどでコンパイル時点でバグを始末してしまえるような気がします、というかコンパイラに機能として組み込むべき?
            たとえば
            int Y;
            Unit pxkg = px * kg;
            Y * pxkg = A * px + X * kg;
            のような形にして、単位系があっていなければ、即エラー。
            機械的にできるならコードレビューチェック化すべきじゃないと思われます。

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

処理中...