パスワードを忘れた? アカウント作成
90892 story

もうやらなくていい昔のコーディングテクニックあれこれ 496

ストーリー by soara
縁側で茶飲み話 部門より

あるAnonymous Coward 曰く、

本家「Old-School Coding Techniques You May Not Miss」に、無くなって嬉しい昔のコーディングテクニックについてのストーリーが掲載されている。

ソフトウェア開発は複雑なものだが、年月とともにその開発プロセスは改善されてきたと言えるだろう。「熟練の」プログラマーであればマニュアルチューニングなどを行ったことも記憶に残っているだろう。しかし今日の開発ツールは、昔であれば手で書かなければならなかったような複雑な機能を自動的に行ってくれたりする。多くの開発者はこれを歓迎している。すでに若いナマイキな奴は、我々のような時代遅れの人間がこれらのことを手で行っていたと気付かないかもしれない。

Esther Schindler氏は古株プログラマーらに「頭痛の種だった昔のプログラミングテクニック」について尋ね、自身の経験も交えた記事をComputerWorldに掲載している。パンチカードとか、ハンガリアン記法とか、覚えているだろうか?

元記事に挙げられている「頭痛の種」には(バブルソートなどの)ソートアルゴリズム、リンクリストやハッシュテーブルの実装、GUIデザイン、「Go To」(そしてスパゲティコード)、マルチスレッドやマルチタスクのマニュアル実装、自己書き換えコード、ユリウス暦の変換等々が含まれている。

/.J諸兄方が昔を振り返ってみて「これは大変だった」と記憶に残っているものや、「今だったらもっと楽なのに」と思われるような懐かしい(?)思い出にはどんなものがあるだろうか? ちなみに本家では、ソートやサーチアルゴリズムなどの基本的な仕組みを理解していることがプログラマーとして重要かどうかといった話に発展してしまっているようだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • てっきり (スコア:5, おもしろおかしい)

    by firewheel (31280) on 2009年05月04日 13時08分 (#1558966)

    「もうやらなくてもいい昔のコーディング規約」かと。

    • まずは詳細なフローチャートを作成し、上司のレビューをうけてからコーディングに入ること。
    • 変数の型が分かるように、変数名の先頭にはintならI、クラスならCのように決められた文字から始めること
    • 変更した部分はコメントアウトして残すこと。
    • メソッド名や変数名を変更する場合には変更許可申請書を提出し、上司の印鑑を貰うこと。

    ええ、もちろん大昔の話ですよ?

    • Re:てっきり (スコア:3, 興味深い)

      by nmaeda (5111) on 2009年05月04日 15時48分 (#1559058)

      このお題を見て、てっきりFortranの桁揃えのことかと。メインフレームメーカーは7桁目に縦線の入ったコーディング用紙を供給していましたね。フローチャートのテンプレートも供給していた。当時は富士通を使っていたので、FACOMってロゴ入りだった。

      FACOMのFortranのテキストにFortranの歌も載っていたな。おおブレネリの替え歌。
      ヤーッフォーッフォートランランランてやつ。

      親コメント
    • Re:てっきり (スコア:2, すばらしい洞察)

      by Takahiro_Chou (21972) on 2009年05月04日 13時35分 (#1558985) 日記

      「もうやらなくてもいい昔のコーディング規約」かと。

      でも、「コーディング規約⊂コーディングテクニック」の様な気もします。
      それなりの合理性が有るノウハウや、バグの作り込みの原因を分析結果を元に、決められたのが、コーディング規約な訳で……ま、「規約」なるモノの常として、大概の場合、決められた、その時から、形骸化が始まる訳ですが。

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

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

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

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

      --
      署名スパムがウザい?アカウント作って非表示に設定すればスッキリさ。
      親コメント
  • by gonta (11642) on 2009年05月04日 13時29分 (#1558982) 日記

    malloc/freeの処理コストってどれくらいかかるんだろう。メモリがバカ高かった時代はmalloc/freeで使用量を厳密に、というのはわかるんだが、ンGB当たり前の昨今、malloc/freeの処理コストの方が高くなったりしないのかな?と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。

    ・・・malloc/free叩いとらんな、最近。

    --
    -- gonta --
    "May Macintosh be with you"
    • by firewheel (31280) on 2009年05月04日 14時28分 (#1559019)

      >malloc/freeの処理コストの方が高くなったりしないのかな?
      >と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。

      チマチマ何回かに分けて取るより一回にまとめて取った方が相対的に安くなる
      ので、「だいたい、このくらい」でまとめて取ってから、それをアプリ内部で
      チマチマ切り刻んで使うというテクニックは昔からあったと思います。

      そしてJVMなんかだと、それを自動でやってくれるので、Javaな人にとっては
      これも「もうやらなくていい昔のコーディングテクニック」の一つですね。

      それから、OSが仮想記憶をサポートして以降は、mallocは実メモリを確保する
      わけではなくOSの管理テーブルに予約するだけなので、ちょっとくらい大きい
      領域を予約しても影響はすごく小さくなってるはずです。

      親コメント
    • by entaille (15816) on 2009年05月04日 17時02分 (#1559087) 日記

      malloc/freeはシステムコールなので呼ぶとコンテキストスイッチが発生します。
      特にCPUのクロック数よりもL2キャッシュのヒット率とかのほうが性能的影響が
      大きいようなメモリレイテンシにシビアなシステム、例えば、
      マルチスレッドでサイズの大きいヒープを頻繁に生成/開放しながら
      沢山のアクセスを受け付けるサーバーアプリみたいな処理系では、
      コンテキストスイッチのオーバヘッドが馬鹿にならないので、
      JVMや.Netのようにヒープの大枠確保しておいて、プロセス内部で
      cpu user timeでやりくりするメモリ管理があったほうが性能的には有利。
      というもんだと理解しとります

      親コメント
      • by CowardDuck (25674) on 2009年05月04日 18時07分 (#1559128)
        > malloc/freeはシステムコールなので呼ぶとコンテキストスイッチが発生します。

        malloc/free はシステムコールではありません。必要であれば mmap や brk などで
        ヒープの大枠を確保し、確保したヒープを切り分けること自体はユーザモードで
        行います。

        というわけで、

        > JVMや.Netのようにヒープの大枠確保しておいて、プロセス内部で
        > cpu user timeでやりくりするメモリ管理があったほうが性能的には有利。
        > というもんだと理解しとります

        JVMや.Net のメモリ管理方式には C に対してあなたが述べたような性能的な
        アドバンテージはありません。
        親コメント
        • by CowardDuck (25674) on 2009年05月04日 18時39分 (#1559145)
          失礼。

          ページフォルトの影響を書き忘れてました。

          そうだな。。。

          ページフォルトが後からじんわり効いてくるのがいやな場合には
          プログラムの初期化部分で大きめに malloc して memset してから
          free しとく必要がありますね。

          でも JVM でもこれを避けようとしたら JVM 自体の初期化処理で
          同じことをやる必要があるはず。ですんでこれは性能的な
          アドバンテージというよりは、プログラムを数~十数ステップ程度、
          短くできるかどうかという問題ですね。

          この意味でのアドバンテージなら確かにありますね。
          親コメント
  • by yellow tadpole (7084) on 2009年05月04日 14時26分 (#1559015) 日記

    紙メディアにカッターナイフで穴をあけたり、ハサミとセロファンテープで切り貼りしたりなど、
    物理的なテクニックは駆使してましたよ。さん孔機の順番待ちをするより早いですから。

    あとはパンチャーのおばさんにお菓子を持って行くのも、ひとつのテクニックです。

    --
    〜◍
    • by nmaeda (5111) on 2009年05月04日 15時33分 (#1559042)

      紙テープを繋ぐツールが色々とありましたね。でも、こんどは高速のテープリーダにかけると、繋いだところでテープがひっかかってちぎれたりするんですよ。

      さん孔タイプライタで打ち込みに集中していたら、テープが引っかかって、横一列に穴が空いていただけっていうトラブルも見かけました。集中していても、たまには脇見をしましょう。

      あと、忘れてならないテクニックが、メインフレームのラインプリンタは筐体が大きくて余裕があるので、ものを隠すには最適ってことです。オヤツとか隠しやすい ^-^)

      親コメント
      • by dameneco (33758) on 2009年05月04日 17時59分 (#1559123) 日記

        >あと、忘れてならないテクニックが、メインフレームのラインプリンタは筐体が大きくて余裕があるので、
        >ものを隠すには最適ってことです。オヤツとか隠しやすい ^-^)

        あの頃のプリンタは五月蝿かったので防音ケースに入れるか隔離されてましたね。
        #ぎりぎり紙テープを見たことのある世代

        親コメント
    • Re:昔のテクニック (スコア:2, おもしろおかしい)

      by nq (16642) on 2009年05月04日 15時32分 (#1559040) 日記

      パンチカードの束をうっかり落としてバラバラになっても、すぐ順番に並べられるように、束の側面に斜めの線をマジックで引いておく。

      親コメント
  • シフト演算 (スコア:3, 興味深い)

    by fcp (32783) on 2009年05月04日 23時20分 (#1559271) ホームページ 日記

    以前はコンパイラーが賢くなかったし乗算が遅かったので、 C 言語の入門書には「y = x * 8; でなく y = x << 3; を使いましょう」などと書かれていたものです。 z = x * 8 + 1; と等価のつもりで z = x << 3 + 1; と書いてバグったのも良い思い出です。

    • Re:シフト演算 (スコア:4, 参考になる)

      by hetareDAIO (17407) on 2009年05月05日 14時13分 (#1559502) 日記

      除算も同じシフト演算で置き換えしてましたですよね。ただ、組み込み系のような、いつまで経っても進歩しないアホなコンパイラを使わざるを得ないケースとかですと、未だ現役の知識なのですw

      それはさておき、

      z = x * 8 + 1; と等価のつもりで z = x << 3 + 1; と書いてバグった

      私の場合は、演算子の優先順位というのを頭に入れるのが面倒でしたので、四則演算の組み合わせでも括弧をつける癖をつけてました。10年前はアホだの無駄だのひどい扱いを受けていましたが、今は「コーディングの鏡」扱いされるのって、複雑な気分です。

      余談ですが、CPUの命令によっては高級言語を意識した命令があって、例に挙げられたような n * { 2,4,8 } + { 0-7 } のような演算を1命令でこなせるモノもあり、コンパイラによってはちゃんと置き換えしてくれるものもありますね。昔はインラインアセンブラ使って人力コンパイルしたりしてました。

      --
      ほえほえ
      親コメント
  • by NOBAX (21937) on 2009年05月04日 13時10分 (#1558968)
    レジスタが少なかったので、スタックに放り込んでおいて、飛び先でPOPして使う。
    80系は裏レジを使いこなす。
    のがコツなんて古すぎて、誰もわからないか。
    • Re:68系は (スコア:2, おもしろおかしい)

      by Anonymous Coward on 2009年05月04日 13時15分 (#1558976)
      今はもっとひどい
      アマチュアは今でも癖のあるアーキテクチャのPICマイコン(8bit品)一辺倒で,姑息なコーディング・テクニックを競い合っている
      親コメント
  • 無敵のコーディング規約でバグの無いソフトウェアを最初から納品してくださいよぉぉぉぉぉぉ!!!

    いや、まあ、昔に比べたらバグの原因が特定しやすくなってるみたいでありますが
    これがコーディング規約の力なのか?

  • 私の場合 (スコア:2, 興味深い)

    by L.Entis (21733) on 2009年05月04日 14時23分 (#1559013) 日記
    自己書き換えコードかな…

    586以降では命令キャッシュを破壊したりと不利益のほうが大きいので使う事はなくなりましたね、さすがに。
  • by chess (7856) on 2009年05月04日 15時39分 (#1559047)

    for文の初期化項での変数スコープがfor文外でも有効だった件。

    可搬性のために
    #define for if(0); else for
    とかやってたよね。

typodupeerror

クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人

読み込み中...