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

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

  • 昔のコンパイラには識別子の長さについて制限のやたらきついものがあったので、無理やり短縮した名前にせざるを得なくなって自分でも何が何やらわけのわからない名前になってしまうことがありました。まぁアセンブラのニーモニックだってそのアーキテクチャに精通してない人にはたとえ規則性があったとしてもなんじゃこりゃ~なわけで、まぁあんな感じです。MASMだって識別子は確か31文字くらいに制限されていた時代があったはず。もっと古いアセンブラのラベルなんて8文字に制限されているものもあったり。

    というわけで、「無理やり短縮した識別子」は「もうやらなくていい昔のコーディングテクニック」です。

    --
    屍体メモ [windy.cx]
    • AppleSoft BASICは識別子の最初の二文字までしか有効でなかったので、気づかずに変数を書き換えてデバッグに苦労した思い出が蘇りました。

      アセンブラが買えなかった子供の頃にはPeek/Pokeでハンドアセンブルとかやったなー(遠い目)

      --
      署名スパムがウザい?アカウント作って非表示に設定すればスッキリさ。
      親コメント
      • by Anonymous Coward
        変数名は頭2文字のみ有効という制限は、AppleSoft BASICというかマイクロソフトのBASICの特徴ですね。
    • by Anonymous Coward on 2009年05月04日 13時19分 (#1558979)

      >昔のコンパイラには識別子の長さについて制限のやたらきついものがあったので、無理やり短縮した名前にせざるを得なくなって

      mallocやstrcmpなんかは6文字制限の名残ですかね。

      それぞれmemory allocateや string compareとかではなかったかと思われる。

      親コメント
    • by Anonymous Coward on 2009年05月04日 14時40分 (#1559024)

      コンパイラというか、リンカの制限だね。それもまあFORTRANコンパイラの制限の名残なんだけど。
      (36ビットワードに1文字6ビットで、6文字までが1ワードに入る)
      http://srad.jp/comments.pl?sid=282950&cid=820917 [srad.jp]

      親コメント
    • L80の外部シンボル6文字制限には苦労させられました。略しすぎて意味不明なので、あの頃はちゃんとコメントを書いてたような。
      今はメソッド名を見れば分かるので、ほとんどコメントは書かなくなりましたが、今度は名前が長すぎて読むのが面倒という…。
      親コメント
    • 処理系側の制約がもう無いし、あんまり好ましくないのは理解してるんですが、
      短縮した識別子のほうが頭に入りやすくて打ちやすいのでつい…。

      # おつむのアップデートに失敗しました

      親コメント
    • by Anonymous Coward
      そうそう言えてる。

      gdgd、wktk
      みたいな変数名付ける馬鹿がいまだにいるよね。
      • でもバランスが必要だと思います。
        若い人の関数名は、年寄りから見ると長いというか、冗長な場合が多いですね(関数名にすべてを語らせようとせずにちゃんとコメント書いてね)。
        簡潔にそれでいて本質をついた命名ができるといいかと思います。
        そういう気がないと、クソ長い関数名が大量発生する困ったコーディング規則を平気で仕込むリーダになっちゃいますので最初が肝心です。

        親コメント
        • 関数の中身を書く場合には短い関数名でもいいのでしょうが、実際にその関数を使ってロジックを組む場合は冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。

          一つのロジックを見直すときに呼び出す関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑な分見落としミスの温床になりやすい。
          どっちかというと関数同士の引数の順序や法則性での統一性の維持に労力を割いた方が余程メンテを考えることになる。

          関数内部のドキュメントの充実以前の問題です。ロジックの記述ミスや手順ミスを見つけるデバッグ側の立場からすると短い関数名でアレコレやっちゃう人は逆に困るんですが。

          # つまりはメンテやる側がソースコードにアクセスする時の工数増やさないで欲しい。って事。
          # 呼び出し先の関数については一回コメント読んだら後は関数内部のロジックの妥当性を見る必要が出るまで
          # 一切見ないで済む位を目標にすべき。
          # 余計な工数自体がメンテやバグ潰しの時のチョンボを誘発する大要因になる。

          関数の命名規則として変な略語や日本語記述とか頭に機能種別をつけたり。というのは一人二人でやって作りきりで後にコード引き継がせる必要がないときにはいいのでしょうが引き継ぎとか考えるとParanoidなハンガリアン規則などでロジック自体の可読性を高める程度がちょうどいい場合も少なくないですよ。

          # しかし、そういうプロジェクトに限って関数名16文字以内とか頭にアレコレつけろだつけないだと
          # と言う所ばかりに拘ったコーディングを要求してくる_| ̄|○汎用機とか十五年前のアセンブラかと_| ̄|○
          ## それよりも引数の統一性と中身の可読性の方が問題だろうと。

          親コメント
          • > 冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。
            という話の論拠や具体例が探しづらいような気がします。

            > 関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑
            使う関数自体が簡単に参照できない場合は確かにそうかもしれません。でもその場合はすでに関数名について選択の余地がない場合では?

            > 短い関数名でアレコレやっちゃう人は逆に困るんですが。
            たしかに限度というものがありますよね。

            > ソースコードにアクセスする時の工数増やさないで欲しい。
            そんなにソースが参照しにくい開発環境って何ですか?とても興味があります。

            親コメント
            • > 冗長な位の関数名の方が組みやすいしメンテやバグ潰しもしやすい。
              という話の論拠や具体例が探しづらいような気がします。

              コーディングする人が20人以上いるプロジェクトでバグ潰しやっていたときのこと(Linuxカーネルが使われるようなリッチになる前の組み込み家電)。
              バグ出しの実際の作業をやってる人たちと一緒に動いていましたが、仕様書どおりではない使われ方をしたときのバグというのも考えてランニングテストする訳ですが、現象が出てすぐだとコード書いた側でもわからないバグがそこそこ出るわけです。何でそういうバグが出てしまったのか再現するのも一苦労と言うのが普通にありました。

              で、そういう場合はデバッグ用のトラップを組み込んでビルドし直してどこに直接の原因があるか絞り込んで行くのですが(そもそもJTAGとかICEとかつなげられる所でだけデバッグしていたのでもないし)、コンポーネント単位で見た場合に簡略な関数名の組み合わせでコンポーネントを組む人(たち)の程、内部ロジックの直感的な可読性も下がっていく傾向がありましたよ。

              つまりは、この手の異常現象を追っかける時にはあるコンポーネントの中では何をやろうとしてるのか?と言うのを迅速に読み取る必要が出てくるのですよ。一行一行逐一読まないと何をやろうとしてるのかわからないコードよりも斜め読みで何をやってるのか、とりあえずのあたりを付けられる方が、原因にたどり着くための絞り込み自体は圧倒的に速くできます。
              もう少し言うならば、外部監査を見越して設計時の設計書と実際の中身のずれを可視化出来るように組みつづけるのを心がけるというのは簡単なようで非常に難しいという事です。
              下手に複雑にしたり独りよがりになったりすると、すぐに外の人は読む気なくしますので。そういう所に決まって深刻なバグが仕込まれていたりもする<自戒を込めて

              > 関数自体のソースコードやコメント・ドキュメントを毎度毎度見ないといけないのは、煩雑
              使う関数自体が簡単に参照できない場合は確かにそうかもしれません。でもその場合はすでに関数名について選択の余地がない場合では?

              昔みたいに関数呼び出しの段数制限が厳しかったりマクロの個数が限定される場合ならまだしも、今時のコーディングだとターゲット機のリソースがよっぽどシビアでない限りは非常に単純な構造のロジックをマトリーショカのように入れ子にして重ね合わせることで大概の物が出来るですよね?
              ソースコードやコメント・ドキュメントをデバッグの度に毎回見ないといけないというのは内部構造の面でも煩雑窮まりない場合が多い気がしますけど。

              > ソースコードにアクセスする時の工数増やさないで欲しい。
              そんなにソースが参照しにくい開発環境って何ですか?とても興味があります。+

              関数の頭の数行を記憶しておけばその関数の概略を覚えられるかどうかというのはデバッグ時の工数に関わってきますよ。特にテスト工程と並行して(第三者が)行うデバッグ工程の場合。
              ソースコード自体が参照しにくいのではなく、そのソースコードが何をやろうとしているかを参照しにくい作りにされてるコードはメンテナンスやバグ潰しが厳しいよね。と言う話ですが…そういうのは作ってる側個人個人の手癖的な差異というか物のとらえ方の違いを吸収して同じ土俵にのっけてデバッグする場合にもやりやすいかしにくいかの勝負を決めますから。

              親コメント
              • ご説明ありがとうございます。
                多分、「冗長」という言葉の捕らえ方が違うんですね。関数の性質を記述することは、それがたとえ叙述的だろうと別に冗長だとは思いません。
                例えば、
                ・その関数が、どのモジュールに属するかとか
                ・その関数は、どのRevから登場したかとか(開発のコードネームが入ってたり)
                ・その関数のテスト方法は、どこのグループに属するとか
                ・その関数は、どこのチームが書いたとか
                ・その関数の重要度は、どのレベルだとか
                そういう情報をうだうだと関数名に仕込めという命名規則をつくっちゃう人が実際いるんです。しかも本人はそれが有用だと信じて疑わない。文句言う奴はタイピングが遅いのでブーたれてるだけだ、とか本気で思ってる。
                で、くそ長い関数名ができて、しかもそれぞれの文節がどういう意味なのかはソースとは関係ない(開発環境も与り知らない)ドキュメントのどこかに書いてあると。
                関数名は簡潔であるべき、という基本的な考えがあれば、たぶんそんなことにはならないと思うんですけどね。

                親コメント
            • 1例で。SafeHandleZeroOrMinusOneIsInvalidクラス [microsoft.com]
              abstractクラスなので、継承されることが前提。なのでここまで叙述的なクラス名でも邪魔にならないし、使い方を間違えることもまずないはず。

              親コメント
        • by Anonymous Coward on 2009年05月05日 2時13分 (#1559329)

          たぶんそれと関連しますが、私は「識別子にゃ日本語を」と思っています。
          英語やローマ字に直そうとするとどうにも冗長で長ったらしくなりがちなので。
          しかも誤訳したりするし。

          とくにいわゆる「業務」ソフトだと(国内企業の)業務用語をわざわざ英訳したりするのが地獄です。
          定訳がある語ならまだいいですがその会社の独自語なんてお手上げです。
          更には既知のはずの語でもその会社ならではの変な(なぜか世間とは違う)用法が有って、どう訳せばいいのやら。

          訳がブレないように対訳表を管理すればいい、という管理主義は面倒なだけです。
          それならそのままの日本語を使うほうがよほどマシ。

          むろんこれには実装言語やDBMSも日本語をきっちりサポートしてくれることが前提となりますが…。

          親コメント
        • by Anonymous Coward on 2009年05月05日 14時09分 (#1559498)
          確かに、ソースを読んでて、test1,test2とかの関数名を見ると、もうアホかと・・・
          変数名は、i,num,hogeとか、
          コメントには、//これを消すと動かないからいらないけど消さないこと
          とか、もうね・・・
          # 親コメと全然関係ない愚痴になってしまった;;
          親コメント
        • by Anonymous Coward
          コメントが無くても、機能を類推可能なクソ長い関数名の方が良いでしょう。
      • by Anonymous Coward
        kwsk
    • by Anonymous Coward
      今時、ループ変数に i を使ってるような酔狂な人はいらっしゃいませんか?

      #とか、わざと書いてみる。
      • by Anonymous Coward on 2009年05月05日 17時22分 (#1559594)

        どうせ、iの代わりにindexとかを使うのだろうから、iで十分。

        親コメント
      • by yyyyyyyy (37036) on 2009年05月04日 17時05分 (#1559090)
        私はループ変数に限らず、識別子には可能な限り(=プログラムの可読性を向上させる限りで)短く意味のないものを使うスタイルに切り替えました。
        私が興味があるのはプログラムそのものであって、識別子ではないのです。
        親コメント
        • by Anonymous Coward

          >私が興味があるのはプログラムそのものであって、識別子ではないのです。

          そんなあなたには

          つ[内部イテレータ]

          をお勧めします。
          ループカウンタ変数なんてなものに煩わされる度合いが激減しますよ。

          #いわゆるループカウンタは外部イテレータです。最も原始的ですが。

          それはそうと、「プログラムそのもの」ってなんですか?
          そこに既に存在してしまっている変数を無視していいなら、関数だって無視していいことになる。他の色々なものも無視していいことになる。…すると一体何が残るんでしょうか?

          • by yyyyyyyy (37036) on 2009年05月05日 2時33分 (#1559340)

            > それはそうと、「プログラムそのもの」ってなんですか?

            なんというかその、プログラムそのものとしか言いようのないものです。アルゴリズムとかデータフローとか一切合切。
            名前は他の名前に変えてしまってもプログラムの実行には影響がありませんので、こういうものは不純物として排除するなり目立たなくするかしたい。

            内部イテレータもよいツールですが、究極的にはコンビネータ論理 [e.tir.jp]のようなものをイメージしています。
            (もちろんこれはやり過ぎです)

            親コメント
      • by Anonymous Coward
        NEXT I
        もたまにいますね。
      • by Anonymous Coward

        何か問題でも?

      • by Anonymous Coward

        それ自体に大した意味があるわけではない変数に大仰しい名前を付けると却って可読性が悪くなるような。

        「i, j, k といったら整数変数」のような古き良きお約束は、お約束が通じる状況でお約束を守っている分には理解の助けになるので、それ自体は現役のスタイルだと思う。

        でも、変数名に意味が無い i とか j とかを文脈無視して使いまわすのは勘弁な!

        • by backyarD (36899) on 2009年05月04日 20時26分 (#1559189) 日記

          お約束が通じる状況でお約束を守っている分には

          そうそう。ネストされているループの外側がjで、内側がiとかになってなければOKかな。

          あと、「もったいないからループ処理のあとでもう1回だけフラグとして使うよ」なんてエコなことを
          されていなければね。

          親コメント
        • by Anonymous Coward

          >「i, j, k といったら整数変数」のような古き良きお約束

          同感。
          なのだけど、グリフ的な問題として、iとjをミスタイプした挙句、ソースを眺めてもなかなか気づかなかった、
          という経験はしたことありませんか?
          いい解決案はないですかね。i の次は ii にするとか?

          • by zymase (12344) on 2009年05月05日 12時54分 (#1559460)

            自分は、スコープの長い変数には必ずdescriptiveな名前を与えるというルールで書いています。つまり、ループ変数でもループ自体が十分長ければ i ではなく意味のある名前を与えるということです。スコープが短く、一画面で見通せるくらいの長さならば i でもOKということにしてます。

            親コメント
          • Re:ループ変数 (スコア:1, 参考になる)

            by Anonymous Coward on 2009年05月05日 2時23分 (#1559335)

            別の角度からの解決策として、
            単語を検索したりハイライトしたりするのが得意なエディタ/IDEを使え、
            ってのもあります。

            たとえばvimなら「i」にカーソル合わせて「*」キーを叩けば、
            「i」が黄色とかにハイライトされます。
            むろん「j」はされません。
            「*」で捕捉されるのは単語単位なので「ii」とかもハイライトされません。

            ちょくちょく「*」で確認する癖をつけると、
            変数名取り違えの事故がだいぶ減りました。
            ていうか殆ど起こさなくなりました。
            これはかなり劇的な効果があったなあと思っています。

            Eclipse(のJava環境)でも、ある単語というか識別子にカーソルを合わせると、
            同じ識別子が灰色っぽくなりますね。

            親コメント
            • google の検索結果みたく、1つめは水色、2つめは黄色というような、 複数の単語をハイライト表示してくれるエディタ(ビューワー)ってないですかね。
              ログ解析の時に便利なんですけど。
              親コメント
            • by Anonymous Coward
              vimで * と # は頻繁に使いますね
              でもあれ、一画面を超える範囲で使われてる名前のミススペルを探すには使いにくいんですよね。
              あと、aVar に対して aVar_variant みたいな名前も柔軟に引っ掛けて欲しいときにちょっと困る。
              • by orangeful (21839) on 2009年05月05日 12時27分 (#1559449)

                1. * または # で検索履歴に「\」を拾う。
                2. / でキーワード検索に入り、Ctrl+P で「\」を呼び出す。
                3. 後ろの「\>」を消して再検索する。

                # ちょっと手順長いですかね?
                # でも g* ではダメなんですよね?

                --
                名物に旨いものなし!
                親コメント
              • by orangeful (21839) on 2009年05月06日 1時56分 (#1559849)

                おっと失敬、化かしてしまいました。

                > 1. * または # で検索履歴に「\」を拾う。
                > 2. / でキーワード検索に入り、Ctrl+P で「\」を呼び出す。

                履歴に取り込んで再利用するのは「¥<aVar>¥」です。

                --
                名物に旨いものなし!
                親コメント
          • by the.ACount (31144) on 2009年05月05日 12時25分 (#1559448)

            ミスタイプは長い名前の方が起きやすいんじゃないか?
            (コピペonlyの人には関係ない話)

            --
            the.ACount
            親コメント
            • by Anonymous Coward
              エディタの補完機能くらい使えよ。
          • by Deasuke (34806) on 2009年05月06日 18時26分 (#1560051) 日記
            そういうとき、(ループの中でiとjを両方使った式を書くときなど)はi1、i2にしたりします。もちろん意味のある名前を着ける方が適切と思われるときは着けますが。
            # ちなみに、私の場合はiteratorでも単順に列挙して順次処理する意味しかない場合はi, j, kを良く使います。
            --
            Best regards, でぃーすけ
            親コメント
          • by Anonymous Coward
            多重ループの最深部で、外ループ制御変数(i)と内ループ制御変数(j)をごちゃごちゃ使った数式書かなきゃいけないときにワケワカランことになったことは結構あるような。

            見易さという意味では、長い変数名でなおかつ似たような名前が大量に出てくる状況と件のi,jのようなもののどっちがマシなのやら。

            # SoCな組込みCPUのメモリマップドなペリフェラル用レジスタは名前が似ているのが多いから大変だぜい
          • by Anonymous Coward
            ループをネストする時は、i1、i2 という具合にしています。

            # 公私含め自分だけしか組まないので、わがままOK。
      • by Anonymous Coward
        そもそも最近の言語はforeachがあるので、ループ変数自体使用機会が減ったなぁ。
      • by Anonymous Coward
        この前、int i, int j, Iterator k というのなら見た

        # 同僚にはバレバレなので AC

最初のバージョンは常に打ち捨てられる。

処理中...