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

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

  • てっきり (スコア: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の歌も載っていたな。おおブレネリの替え歌。
      ヤーッフォーッフォートランランランてやつ。

      親コメント
      • by Jubilee (20038) on 2009年05月06日 20時46分 (#1560092)

        Fortranの歌といえば、20年ほど前に口の悪い友人はコウガマンの替え歌を教えてくれました。
        「要らん使わん、フォートランー」てやつ。

        プログラミングをしない私にはなんのことか分かりませんでした。

        ていうか、たぶん今となってはコウガマン自体がセピア色の想い出。そもそもこのセピア色ってのが銀塩写真をある程度知らないと意味不明なんで、今時の若い者はきっと使わない言葉なんでしょう。

        --
        Jubilee
        親コメント
      • by Anonymous Coward
        段落ごとにフィードを入れておいて、切り貼りするときの糊代を確保しておくことかと。
        ええ、カップラーメンの汁が飛んで読み取りエラーする紙テープでしたよ。
        • by Anonymous Coward
          COBOLの行番号でしょう。
          最新のCOBOL言語仕様がどうなってるか知らないけど、今じゃHOST系でも
          桁位置合わせ(A欄、B欄)の意味しかないし。

          前はまじめに行番号もコーディングしておくと、
          カードぶちまけたときの手SORT時に役にたったけどね。

          そういう意味じゃテープ(紙のね)は落としても散らばらないから、
          FALLSAFEではあったな。

          FORTRANなんかだと、カードぶちまけたときはどうしてたんだろう。
          • by Anonymous Coward

            断面を斜めに引いた線を見ながらそろえますよ。

            • by Anonymous Coward
              線を引く前に限ってぶちまける気がするんですが、そうでもないんでしょうか。
    • Re:てっきり (スコア:2, すばらしい洞察)

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

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

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

      親コメント
    • by Arc Cosine (35004) on 2009年05月04日 23時46分 (#1559282) 日記

      変更した部分はコメントアウトして残すこと。

      それと変更した日付と変更した人の名前を残すってのがありましたねー。
      2004年ごろの話ですけどね!
      #CVSやSubversionが今ほど普及していなかった頃の話
      #多分今も普及してないだろうけど、あの部署

      親コメント
      • >変更した日付と変更した人の名前を残す

        これは今でもあっちこっちで見受けますよねー。

        で、変更した人に詳細を聞きに行こうとしたら8割の確率で

        「あ。その人とっくに辞めてますよ」 orz

        だから、あんまり役に立たないんだよねー。

        # ちなみに私も今は「とっくに辞めてますよ」の側だから、これ以上、つっこまない(笑)
        --
        clausemitz
        親コメント
      • by Stealth (5277) on 2009年05月05日 5時59分 (#1559367)

        CVS で管理しているところでもそんなのはありましたけどね。
        何のための CVS なのかと……。

        親コメント
        • by yasu (7) on 2009年05月05日 19時10分 (#1559673) ホームページ

          「うちでは変更をCSVで管理しているんだ。」
          (ああ、CVSか… subversionにすれば良いのに。)

          っhistory.csv

          --
          HIRATA Yasuyuki
          親コメント
          • by sakamoto (8009) on 2009年05月05日 20時26分 (#1559710) 日記
            この前、辞書つくりに協力したけど、管理が Excel だったよ。 なかにはあるんじゃないかな?上司が Excel しか使えない職場だったりすると。
            --
            -- 哀れな日本人専用(sorry Japanese only) --
            親コメント
          • by Anonymous Coward

            野暮ですがいちおうコメントしますと、
            そういう連中が言う「管理」は非常にしばしば、管理になってない恐れが有るので最初から眉唾しとくべきです。

            というのは、たとえばバージョン管理についていえば、

            「xx月xx日。by xxx君。xxxという修正をおこなった」
            というコミットログみたいな情報は残って(=管理して)いるんだけど、
            肝心のファイルの「内容」をバージョン毎に保存していなくて、
            過去の版に戻すなんて神業は不可能!
            どうしてもやりたくなったら、ログのxxx君を呼び出して記憶を手繰らせる!

            …なんてことがよく有るんで。

            老人に同情するならば、悪い(あえて逆説的にいいます)のはム

      • by bero (5057) on 2009年05月07日 12時02分 (#1560272) 日記

        >変更した日付と変更した人の名前を残すってのがありましたねー。

        GPLv2

        2-a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

        2-a) あなたがそれらのファイルを変更したということと変更した日時が良く分かるよう、改変されたファイルに告示しなければならない。

        誰も守ってないと思うけどな

        親コメント
      • by Anonymous Coward

        転職したらそんな職場だった。
        修正コメントであふれかえって、ただでさえ可読性が低い汚いソースがよけいに読みにくくしてしかたない。
        もう辞めたい。。。

        • by seoulflowerunion (37424) on 2009年05月05日 16時22分 (#1559566)
          > ただでさえ可読性が低い汚いソースがよけいに読みにくくしてしかたない。

          同様に可読性を損なうコーディング規約に「タブではなくスペース4文字でインデント」がありますね。この話を未だに「好みのエディタ」のような宗教論争と同列に扱う輩が多いことに辟易します。
          --
          格差社会ニッポンを変える!
          貸し渋り・はがしの温床、大銀行の厳正審査をやめさせよう!
          親コメント
          • by kacha (13067) on 2009年05月05日 17時02分 (#1559582) 日記

            > 同様に可読性を損なうコーディング規約に「タブではなくスペース4文字でインデント」がありますね。

            おや?

            スペースインデントって結構使ってるんですけど、NGだったんですか・・・ (+_+)

            個人的には可読性を高めるためにスペースを結構多用してます。

            スペースならどのエディタで開いてもインデントの深さが一緒になるので、

            違うエディタで開いたり、他の人の画面でコーディングをチェックしてあげる時

            タブだと設定によって崩れて見えて読みにくいんですもん

            # タブでもスペースでも、2~4文字がちょうどいい人です
            # ネストの深さや種類によって、2文字だったり4文字だったり
            # はたまたタブだったりで、結構いい加減ですが (^-^;

            親コメント
            • by Anonymous Coward
              それが、場所によって3桁のスペースになってたりするんですよね~

              後、プログラマのレベルが違いすぎると、ほんの2行程度の内容が理解できなかったりする...
          • by fcp (32783) on 2009年05月05日 18時11分 (#1559632) ホームページ 日記

            僕はたいていの言語で「スペース 4 文字でインデント」派です。

            同様に可読性を損なうコーディング規約に「タブではなくスペース4文字でインデント」がありますね。この話を未だに「好みのエディタ」のような宗教論争と同列に扱う輩が多いことに辟易します。

            インデントをタブにするかスペースにするかとか、何桁にするかとかって、まさに「『好みのエディタ』のような宗教論争と同列」だと思っているのですが、何が違うのでしょうか。どちらも、選択肢がいろいろあり、どれも一長一短で完璧な解はなく、結局好みの問題だという点でよく似ていると思います。

            親コメント
            • by seoulflowerunion (37424) on 2009年05月06日 14時56分 (#1559986)

              > 何が違うのでしょうか。

              インデント論争は、文書構造の視覚的表現を失うリスクの有無という観点から、本質的にどのエディタでもリスクに差がない(と思われる)エディタ論争と異なります。

              ソースコードにおけるインデントとは、プログラムの文書構造を視覚的に表現するための手段です。視覚的に表現できれば何でも良いのでタブでも空白4文字でも8文字でも本来であれば問題ありません。しかしながら多くの場合、繰り返し流用や保守作業を続けていくと、空白で表現されたインデントは崩れやすく、コードブロックの判別が難しくなる傾向があります。6文字や7文字といった切りの悪い数の空白のインデントが散在し始めると、どこまでを一つのブロックと判断してよいのか分からなくなり、可読性を大きく損ないます。

              タブの場合は、一文字でインデント一つを表現できるので保守性が向上します。また、タブが一文字削除されるとインデント一つ分大きく変動するので異常を即座に見つけやすいという利点もあります。

              タブの表現がエディタによっては空白4文字か8文字の違いがあるので見た目が変わってよろしくない、なので空白4文字でインデントせよ、という主張がありますが、私は同意できません。上述のように、インデントとはプログラムの文書構造を表現するものであって、外観を表現するものではありません。8文字の環境の方は、8文字字下げされていれば、それがコードブロックを意味していると理解すればよいのであって、下げられたカラム数が8なのか4なのかはどちらでもよいからです。

              一方で、ソースコードの中には、視覚的な位置が重要な意味を持つ記述もあります。例えば構造体配列を用いたテーブルの定義などで、各メンバの初期化子の頭を揃えて記述して可読性を向上させるなどのケースです。このような場合にこそ空白を用いて頭揃えすべきで、タブは絶対に用いるべきではありません。仮にタブを用いて頭揃えした場合、タブ位置の異なる環境では、テーブルが大きく崩れて可読性を損なうでしょう。

              そもそも、プレーンテキストでソースコードを記述しなければいけない以上、文書構造と外観を切り離せないのは最早どうしようもなく、このような議論がつきまとうのは宿命とも言えるのですが、明日から全員Cソースを XML で書けと言って世のC言語エンジニア全員を敵に回すのもよろしくないでしょうし、しょうがないので現場ではうるさくは言わないようにはしていますが。

              --
              格差社会ニッポンを変える!
              貸し渋り・はがしの温床、大銀行の厳正審査をやめさせよう!
              親コメント
          • by komakisakio (33768) on 2009年05月05日 18時06分 (#1559627)
            4文字かどうかはともかく、タブ幅を推測する手間が無駄なのでスペースでインデントしています。
            タブにすると可読性が上がるような(上記の手間に見合う)何かがあるのでしょうか?
            親コメント
            • by Anonymous Coward
              タブ幅が何桁であっても、破綻ないようにタブを使うのが基本でしょう。
              というか、普通にやれば、そうなります。

              最悪なのは、エディタをタブ8桁に設定して、スペース4文字とタブを混ぜる書き方。
              んなことするなら、タブ4桁に設定しろっつーの。

              自分好みに自動整形すりゃいいじゃんという話もありますが、
              ホワイトスペースの変更が許されない場合もありまして・・・
              • by komakisakio (33768) on 2009年05月05日 20時09分 (#1559705)
                つまり、

                ・自分好みの幅で表示できるからタブの方が優れている
                ・スペースを混ぜると破綻する

                ってことですね。

                > 最悪なのは、エディタをタブ8桁に設定して、スペース4文字とタブを混ぜる書き方。

                タブ幅を8以外に変えられないエディタがあるとか、そんな事情ですかね。今時ないとは思いますが。
                親コメント
              • by firewheel (31280) on 2009年05月05日 21時48分 (#1559757)

                >タブ幅を8以外に変えられないエディタがあるとか、そんな事情ですかね。

                タブ幅を変えられることを知らない初心者があるとか、
                未だに手動でインデントを付けてる初心者があるとか、
                そんな事情では。

                まあ普通は

                • 同一組織内の同一プロジェクトであればタブ幅は統一しておく。
                • インデントはタブで行う。
                • 他の異なるタブ幅を採用している組織とソースの受け渡しする必要がある場合のみ、スペースに変換して渡す。
                • それ以外で問題になった場合は、必要に応じてオートインデントで整形する。

                ぐらいでいいと思うんだけどなあ。

                すくなくとも「スペースにしたから可読性が上がる」ってのはちょっと違うだろと。
                オレの目には四文字分のスペースも四文字幅のタブも、見た目は同じにしか見えません。;-)

                親コメント
              • by funakichi (28497) on 2009年05月05日 23時24分 (#1559795)

                リーナスおじさんの「タブ幅は8桁で決まり!」主張 [linux.or.jp]を誰かフォローしとくべきでは?

                #この話題はおじさんホイホイなんだし
                 

                親コメント
              • by cassandro (6035) on 2009年05月06日 20時23分 (#1560079)

                > リーナスおじさんの「タブ幅は8桁で決まり!」主張を誰かフォローしとくべきでは?

                 深いネストはロクなもんじゃない、同感ですね。3段階とまでは言わないですが、5段以上になるケースは僕の場合は希です。

                # 確かに論理構造の劣悪さに着目しないで、単なるプログラミングスタイルの問題と
                # 捉えている人は多いですね。

                親コメント
          • by iwa (2980) on 2009年05月07日 15時27分 (#1560436)

            うちではハードタブによるインデントは禁止にしますた。
            インデンテーションの処理自体はエディタがやってくれるので手間は変わらず、
            サーバ上でviだのlessだのを使わざるを得ない場合でもインデントが狂わなくて、
            少し幸せになれました。

            親コメント
        • by Anonymous Coward

          >もう辞めたい。。。
          その気持ちは嫌と言うほど理解できるが我慢しろ。
          日本のIT業界なんてそんな所ばかりだ。

          技術力があるって触れ込みの所でもそんな有様だ。
          おそらく7~8割くらいはそのレベルだし、
          残りの2~3割にしても「それよりはマシ」の域は出てない。

          • by Driver (32138) on 2009年05月05日 12時32分 (#1559451) 日記

            そんなソースに出会ったことはありますが・・・
            そもそも、作り自体が悪いのもあって一から作り直しました。
            コメント?
            バグつぶしのコメントをとっておいてもしょうがないでしょう。
            仕様のコメントなら大歓迎ですが。

            親コメント
          • by Anonymous Coward

            親コメントとは別人ですが、数年前に入社以来同じ悩みを抱えてました。
            やっぱりどこもそんな感じなんですかね…。

      • by Anonymous Coward

        おつむがある時点で止まってらっしゃる人々(個人または集団)では、
        新しい画期的なツールなんてものは
        存在を信じてもらえないし、
        現物見せようとしても見るのも渋るし、
        仮に見せるところまでいけても、
        それの振る舞いが安定していることを信じてくれない。
        「偶然動いたんだろ。いつでも動くかどうかなんて信用できない」と。

        まるで幽霊か宗教のような扱いを受けます。

        もっとも本当に幽霊宗教に染まってるのはソッチのほうなのは皆さんご存知の通りです。
        そういうところに限って、逆に自分らが今まで使ってたツールについては、
        それがどんなに怪しげなものであろうとも「信頼」します。つまり

    • by nn1963 (35819) on 2009年05月04日 13時57分 (#1558996)

      >>変更した部分はコメントアウトして残すこと。

      変更部分どころか、その関数の処理概要を書く人いませんでした?
      informix 4GLなんてものを使っているプロジェクトでPMやってたとき、
      設計書の仕様よりコメントのほうが実態に近いので、ソース読んで
      関数の関連とコメント行を抽出する管理PGを作らせようかと思った
      ことがあります。途中でそれどころじゃなくなったけど。

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

      親コメント
      • by the.ACount (31144) on 2009年05月05日 12時29分 (#1559450)

        私、コメントで処理概要を書いてから、それをプログラムに直す人です。

        --
        the.ACount
        親コメント
      • by Anonymous Coward

        >変更部分どころか、その関数の処理概要を書く人いませんでした?
        今だと広く普及していますね。

        javadocとかで。

        >設計書の仕様よりコメントのほうが実態に近いので、
        これは、………

        #だから設計書なんてものを後生大事にする必要はないとアレほどブツブツ...
        ##これだからプログラミングをやったことのないジジイどもはブツブツ...

    • by nofuture (17983) on 2009年05月04日 22時29分 (#1559248)
      >「もうやらなくてもいい昔のコーディング規約」

      ●ドキュメンテーション

      頭痛のたねが無くなってすっきりです。
      親コメント
      • by nobuhiro (5244) on 2009年05月05日 13時08分 (#1559469) ホームページ

        私は無くしたわけではないけど、受託開発の見積りでドキュメントをアンバンドルしてます。

        開発と同じコストがかかるドキュメントを要求されるケースはあまりないです。ほとんどは(追加費用がかからない) README 程度、細かくてもユーザマニュアルや導入ガイドまで。関数やプログラムの説明を求めるような詳細ドキュメントを要求されたことはないですね。

        --
        親コメント
        • by Anonymous Coward

          >開発と同じコストがかかるドキュメントを要求されるケースはあまりない

          そりゃそうだろう。「だから」、ドキュメントを請求されたうえで、その御代は値切られるんだよorz

          野蛮な話だが、まあこんなことも有るわけですよ。力関係がおかしい場合には。

          そういえば、一番最初に提唱された自由経済主義とは、
          契約する両者がともに「十分な情報を受け取ったうえで」契約をどうするか判断する、
          というスタイルを指すのだそうです。
          が、その情報じたいにお値段をつけられて「払えるなら渡すよ」とか色々ややこしい縛りが入ってきた場合、これも自由経済主義だと呼べるんだろうか??

    • by Anonymous Coward
      先輩・他社のプロフェッショナル・偉い人に聞くこと
      ググればたいていのことは解決する。
    • by Anonymous Coward

      自分が何時代に居るのか最近判らなくなってきています。

      新人が「フローチャートの書き方がよく分からなかったのでもう少し勉強して書けるようになりたいです」という
      日々の報告を上げてくるような組織のそばで働いています。やめさせた方がいいですか?いや、直接教育担当では
      ないので、口出ししないように言われているのですが。

      もちろん、オブジェクト指向だ何だといっても、中では順序だって処理する部分が絶対にあるわけで、その部分の
      処理の流れを図で示せる能力は必要だと思いますが....新人が悩んで自信を無くしかけるほどまで深く掘り下げる
      場所じゃないとおもうんですよね。

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

        by Anonymous Coward on 2009年05月05日 2時04分 (#1559328)

        >直接教育担当ではないので、口出ししないように言われている

        その身分制度(の過剰さ)も、かなりおおきな害悪なので、どうにかする努力をしたほうがいいです。

        問題指摘なんてのは「社内で一番最初に気づいた奴が言う(という権利が有る)」ことにするのが一番です。
        それを採用するかどうかはまた別としても、まず言う権利くらい全員に与えないと、なにしに「会社」に大勢が雁首揃えてるのか判りません。

        >フローチャート

        無数にある実装(/設計)上必要なもののうちのごくごく一部でしかないですね。
        たまたま一本の長い流れが発生したときにそれを記述しやすいというだけなので、フローチャート自体がデザパタとかと同様に「特定の状況では有効、別の状況では逆効果」というものでしかないです。
        そういう状況になったときには「そういやフローチャートなんてものもあったな」と押入れから引っ張り出せばいいものであって、常に机に置いておくほどのもんじゃないです。

        そして、他の人がいってるように並列処理も書けないし、OOPを引き合いに出すまでもなく状態変化やマルチ状態も書けない。つまり「コンテキスト」を記述する能力が無いんですよねフローチャートには。バグは処理そのものよりも処理と絡むコンテキスト(の誤用)に宿ることが多いので、それが見えにくいフローチャートはあんまり役立たないことが多いなあ。つまり本当に数少ない特定の場面でしか有効ではなく、大抵は邪魔。

        フローなんぞより、データ構造のほうが余程大事ですし、データ構造を基準に見れば全体が判る「ように設計」すればますますバグりにくくなります。自社を倒産させたくないならば狙うべきはそっちですね。

        親コメント
      • by komakisakio (33768) on 2009年05月04日 20時44分 (#1559201)
        「フローチャートが書けなくて死んだ人間はいない」と言っておく、とか。

        #フローチャート書いてる暇があったら、なんでもいいから動くもものを作った方が勉強になると思う。
        親コメント
        • by Anonymous Coward

          同意

          フローチャートなんて無くても困らない
          必要になるのは、やたらとフローチャートに拘る年代の方に見せる資料を作成する時かなー。

          • by Anonymous Coward

            最近の開発環境でフローチャート書けるだろうか。並列処理は書けないのよね、あれ。

        • by Anonymous Coward
          教育業界に微妙に身を置く人として。

          並列処理云々という前に、プログラムを書くために必要な論理思考を伴わない人(学生)というのが結構いるのですよ。
          雛形(#include <stdio.h>~int main(...){...})だけとりあえず与えて、中に必要な流れを書いていくということをやらせると、
          どういう手順でやっていったらいいかまるで考えられないというのがごろごろと。

          だからとりあえず必要なことを列挙させ、線でつなげさせて必要なロジックを埋め込んでいってフロー化させる。
          「いらないだろう」という人たちは、半ば無意識にでも「どういう手順でやっていったらいいか」がつなげられる人たちなんです。
          並列云々へ行く前に、思考力を鍛えるためにはなんらかの形での目で見える形にするのが必要だと思います。

          でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…
          • by cassandro (6035) on 2009年05月06日 20時12分 (#1560075)

            > プログラムを書くために必要な論理思考を伴わない人(学生)というのが結構いるのですよ。

             御意。居りますなあ。一年位でアプリからカーネルまで出来る様になって欲しいのですが、前途遼遠・・・

            > でも、フローチャート以外の代替案(現場でも使いそうなもの)ってどういうのがいいのだろうか…

             NSチャート、PAD位しかチャートを知らないのですが、どれも一長一短がありますね。しかし本来はコードを書く前にチャート等で論理構造を検討する必要がある人達も時代の流れでチャート等を書かなくなり、その帰結として「なんじゃ?こりゃ?」なコードの大量生産、これが近年の傾向では無いでしょうか。もっとも、チャート等で論理構造の検討を行うとか、エレガントなコードが書ける人も求めると言うのが(特にお金の面で)難しくなっている事も理由だとは思いますが。プロジェクト管理で品質について考える場合でも、通常は表層的なバグ数のカウントに終始している訳で、コードの安定性の様なものはバグの原因にさえならなければ無視、無視出来ない場合は大炎上ですね(少なくとも僕が絡んでいる所ででは、ですが)。

             ルータ構成ツールにステートチャート(UMLのではなくて、ステートマシンの記述の方)の作成がプログラミングになるものがあります。エレガントなコードを志向するのが死に筋なら、その様なアプローチもありなのかな、と思っています。

            親コメント
          • by Anonymous Coward
            PAD

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

処理中...