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

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

  • by Anonymous Coward on 2009年05月04日 14時11分 (#1559005)
    あれを未だにやめず使う人の気が知れんです。
    • 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
          やめてみると不要だってわかるよ
          間違ったらエラーになるようなケースが大半ですんで、だからそれよりもっと重要な情報を入れたくなる。
      • 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

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

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

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

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

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

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

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

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

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

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

              --
              むらちより/あい/をこめて。
              親コメント
              • と、いうことは、略されてさえいないのであれば、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の面で有利じゃないですかね?
                完璧だけど多くの手間が掛かる方法より、抜けがあっても僅かな手間で済む手法の方が開発現場では好まれると思います。
          • アプリケーションハンバリアン、はじめて知りました、
            でもこれ、単位系の整合性は、実行するまでもなくコンパイルレベルでチェックできるんですね。
            テンプレートメタプログラミングなどでコンパイル時点でバグを始末してしまえるような気がします、というかコンパイラに機能として組み込むべき?
            たとえば
            int Y;
            Unit pxkg = px * kg;
            Y * pxkg = A * px + X * kg;
            のような形にして、単位系があっていなければ、即エラー。
            機械的にできるならコードレビューチェック化すべきじゃないと思われます。
    • コーディング規約がいい加減な所に助っ人に行った時は、ハンガリアン記法で書いてます。
      「MFCのソースの書き方に準じております」と言えば、文句を言われる事は少ないので。
      --
      notice : I ignore an anonymous contribution.
      親コメント
      • by Anonymous Coward

        逆にJavaでハンガリアン記法を押しつけられそうになったときは「Sunコーディング規約に従っています」でたいてい切り抜けられますね。

    • by Anonymous Coward

      とりあえず、ここにぶら下げておくか

      7bit文字コード自体を引きずって、変数名に英語だけ使うのは古い。
      今時は日本語のひらがなや漢字混じり変数名を使う。分かり易さが一番だろ今時。

      #オープンソース界隈ではgccもまともに対応できていなかったけど、もう大丈夫なかぁ

      • Re:変数名 (スコア:1, おもしろおかしい)

        by Anonymous Coward on 2009年05月04日 18時28分 (#1559139)
        コボラーを呼び出すなんてずるいぞ
        親コメント
      • by backyarD (36899) on 2009年05月04日 20時55分 (#1559209) 日記

        んでもって数年後には「変数名の誤変換はいい加減にしてほしい」って話題でもりあがるのですね。

        「Dim 返り値 As Boolean」というコードを巡って..

        ・「普通は戻り値だろう?」
        ・「返り値でも日本語としては間違えてはいない(根拠を示しながら)」
        ・「いや、どうでもいいから返り血だけはやめてほしい」

        とか

        親コメント
        • by sumeshi0206 (12305) on 2009年05月07日 16時02分 (#1560462) 日記

          英語の変数名のつけ方でも同じ事が言えるけど
          Booleanで"返り値"という変数名はわかりずらい。
          例えば"○○が存在"とか"入力エラー"だとtrueのとき存在するんだなとか入力エラーなんだなってわかる。

          親コメント
      • by Anonymous Coward

        マルチバイトな変数は入力しづらいのがね。
        Enumみたいな、コード補完で一覧表示されるようなのは、一切打ち込むこと無いから良いと思うんだけど。

      • by Anonymous Coward

        こんな感じ?

        #include <stdio.h>
        #include "jident.h"

        整数 主関数(空虚)
        {
            整数 い;
            於 (い = 0; い <= 100; ++い) {
                若 (い % 3 == 0 && い % 5 == 0)
                    整形印字("ひずばず\n");
                或 若 (い % 3 == 0)
                    整形印字("ひず\n");
                或 若 (い % 5 == 0)
                    整形印字("ばず\n");
             

        • by kawa-t (37052) on 2009年05月06日 2時12分 (#1559857) 日記
          (define それぞれで for-each)
          (define-syntax 算法
            (syntax-rules ()
              ((_ x ...) (lambda x ...))))
          (define 表示する display)
          (define-syntax 条件は
            (syntax-rules (他)
              ((_ (他 x ...)) (begin x ...))
              ((_ (e1 e2 ...)) (when e1 e2 ...))
              ((_ (e1 e2 ...) e3 ...)
               (if e1
                   (begin e2 ...)
                   (条件は e3 ...)))))
          (define-syntax 論理和
            (syntax-rules ()
              ((_ x ...) (and x ...))))
          (define 零ですか zero?)
          (define 余り modulo)
          (define 改行 newline)
          (define-syntax する
            (syntax-rules ()
              ((_ x ...) (let x ...))))
          (define-syntax これが
            (syntax-rules ()
              ((_ x ...) (if x ...))))
          (define 減 -)
          (define 対 cons)

          (それぞれで (算法 (い)
                            (表示する
                             (条件は ((論理和 (零ですか (余り い 3)) (零ですか (余り い 5))) "ひずばず")
                                     ((零ですか (余り い 3)) "ひず")
                                     ((零ですか (余り い 5)) "ばず")
                                     (他 い)))
                            (改行))
                      (する 繰り返し
                            ((元 100) (結果 '()))
                            (これが (零ですか 元)
                                    結果
                                    (繰り返し (減 元 1) (対 元 結果)))))  

          ;; MzschemeとGaucheで動きます。Gaucheだと最後にエラーが出ますが。何でだろう。
          親コメント
      • by Anonymous Coward
        国際化対応で海外のメンバーにソース引き継ぐことになって文句を言われる破目に。。。
    • by Anonymous Coward
      それはダメな人を簡単に見分けることができるので 便利といえば便利?

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

処理中...