パスワードを忘れた? アカウント作成
11983625 story
プログラミング

コードを特に良いものとするのは何? 98

ストーリー by headless
品質 部門より
本家/.「Ask Slashdot: What Makes Some Code Particularly Good?」より

何がソースコードを特に「良い」ものとするのかについて開発者が話すとき、一握りの特徴が繰り返し言及される傾向がある(動作する、読みやすい、テストできる)。皆さんなら何をリストに加えるだろうか。

元記事のITworldでは良質なコードの特徴として、以下の8つを挙げている。

  1. 正しく動作すること
  2. 読みやすいこと
  3. テストできること
  4. メンテナンスしやすいこと
  5. きれいに整形されていること
  6. 変更しやすいこと
  7. シンプルであること
  8. 効率が良いこと
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2015年03月29日 19時25分 (#2786941)

    車輪の再発明はしないこと

  • 追加で (スコア:4, すばらしい洞察)

    by Anonymous Coward on 2015年03月29日 19時47分 (#2786953)

    コメントが不足なく記述されてること。
    コードの意図が汲み取り易く書かれていること。

  • by wolf03 (39616) on 2015年03月29日 19時41分 (#2786950) 日記
    2,4,5,6,7はひとまとめで良い。
    1,3も一つに出来そう。
    よって、三パターンで収まるでしょう。
    • by Anonymous Coward on 2015年03月29日 20時19分 (#2786971)

      さすがにそれは乱暴じゃね。

      たとえばレガシーコードなんかで、「正しく動作してるけどテスト不可能」なんて珍しくも無い希ガス

      親コメント
      • by Anonymous Coward

        その理屈だと、正しく動作していればそれでいいという主張に近い。
        確かに、レガシーコードなど、変更の必要がないものは 1 だけで良さそうに見えますね。
        そして、レガシーコードを修正する羽目になるときに、恨み言の一つや二つを吐きたくなるという話は時々あります。

        レガシーコードでない、変更が頻繁に必要になるコードでテスト不可能というのは、良質なコードの特徴の資格を欠いているといわざるを得ません。

  • よいチームが一番 (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2015年03月30日 8時07分 (#2787145)

    結局、悪いコードを指摘してくれて、議論をできるチームが一番。
    変に気を使って指摘できない雰囲気や、
    勝手に怒り出すバカが混ざると、コードの品質はがた落ちだとおもう。

  • by yoshimo (15798) on 2015年03月30日 9時38分 (#2787181)
    処理(クラス)の結合度の低さ(独立性の高さ)が一番大切だと思うんだけど。

    自分が知らなくてもよいことは知らない、相手が何をしてくれるひとかは知っているけど、具体的に何をどうやっているのかは知らない。

    プログラマでこういう概念をわかってくれる人は結構少ない。
    • by Anonymous Coward on 2015年03月30日 10時43分 (#2787238)

      結合度の低さは確かに重要ではありますけど、このリストに挙げられる目標と言うより、実現するための手段なんじゃないですかね?
      「結合度の低さ」そのものが目標になってはいけないと思います。

      親コメント
  • 欲を言えば予算にも余裕を持ったスケジュールだと嬉しいですね

  • by Anonymous Coward on 2015年03月29日 19時20分 (#2786937)

    きちんと設計されたデータ構造があればコードなんてクソでもよくね?

    • by Anonymous Coward

      二次元配列なんてxとyどちらから走査しても良いと。

    • by Anonymous Coward

      プログラム=データ構造+アルゴリズム

      • プログラム=データ構造+アルゴリズム

        コンピュータ・システム開発を仕事にする続にコの業界の人たちの使う

        「ロジック」

        という隠語は上記のうちどの部分を意味する・含む/含まれるものなのでしょうか?

        // あるいは包含関係などない捩れの位置にあるとか世界線の彼方の事象であるとか。。。

        親コメント
        • by plauda (46850) on 2015年03月29日 23時12分 (#2787066)

          どっちかというと「アルゴリズム」寄りな考え方ですが、
          データ構造、アルゴリズムなどプログラム・コードレベルの概念とは切り離して考えたほうが良い言葉ですね。

          ロジックは文字通り「論理」です。
          開発者は、システムをうまく制御するための論理を考えます。
          その論理を実現するために適切な「データ構造」と「アルゴリズム」を決めて、それをコードに起こす訳です。
          そのため、「ロジック」に誤りがあった場合、コードレベルでは「データ構造」、「アルゴリズム」の双方に修正が必要になることもよくあります。

          という訳で、「ロジック」というのは「大まかなプログラムの処理手順」ぐらいの理解でよいかと思います。

          親コメント
        • by Anonymous Coward

          プログラム=ロジック+コントロール

  • 「mallocの返り値チェック」は有名かと思いますが、そういったエラーチェックを丁寧にやっているかどうか。
    例外のある言語で、例外のハンドリングをきちんと(ルールを決めて)やっているか。

    「実際に使われるアプリケーションのソースコードの半分は、本来の処理ではなくエラーチェック」的な話もどこかで見た覚えがありますので、基本かもしれませんが。
    基本を守るのが難しい、ということはあるかもしれません。

    私も、c++で"out of range"をやらかすことがあるので、気をつけなければ。

  • by Anonymous Coward on 2015年03月29日 19時47分 (#2786954)

    休息。休息。休息。

    私は休息に1票入れます。

    • 正しく動作すること
          >コーヒーが出てくる。
      読みやすいこと
          >取扱説明書が。(セブンイレブンコーヒーのHOT/COOLボタンの話ではなく)。
      テストできること
          >テスト用の豆が添付されているとベスト(そこなのか?)。
      メンテナンスしやすいこと
          >洗いやすい(超重要)。
      きれいに整形されていること
          >見た目が綺麗だと嬉しい。味に関係ないことはよくわかっているが見た目が良いに越したことはない。
      変更しやすいこと
          >コーヒーの味のバリエーションが。
      シンプルであること
          >操作が。
      効率が良いこと
          >豆の使用量が少ない。

      ごめんなさい、単にわたしが職場にほしい物を書いただけです。

      親コメント
      • by Anonymous Coward

        変更しやすいこと
                >コーヒーの味のバリエーションが。

        マジレスするとエスプレッソマシンでは味のバリエーション変更できないぞ。
        役割を超えたコード書くのは間違いだ。

        • by Anonymous Coward

          エスプレッソマシンみたいなバッチ処理機で、豆を変更しようと、コーヒーの味のバリエーション変更できないとする論拠を伺いたい。

          • by Anonymous Coward

            そう、豆や焙煎を変えるのが基本で次にメッシュの荒さ、タンピング、バスケットの変更で微調整。
            エスプレッソマシンがロブスタベースのブレンドをマンデリンベースと感じるように変更する事はできないし、試みるのも間違っている。

    • by matlay (32743) on 2015年03月29日 21時59分 (#2787025) 日記

      一度目の休息は自分の為。
      二度目の休息はみんなの為。
      三度目の休息は念の為。

      でしたっけ?

      --
      #存在自体がホラー
      親コメント
    • by nekopon (1483) on 2015年03月30日 10時27分 (#2787219) 日記
      cpu「nop
      親コメント
    • by Anonymous Coward

      それから十分な賃金が支払われていること

      • by Anonymous Coward

        十分な実力を備えた人員は?

  • by plauda (46850) on 2015年03月29日 20時24分 (#2786975)

    「正しく動作すること」というのは、「良質なコードの特徴」といってもコードを見ただけでは分からないですよね。
    そういう訳で、全体的に「特徴」というよりも「希望(うすいのぞみ)」として捉えたほうが腑に落ちます。

       *   *   *

    1,3は一つにまとめたい気がする。テストができないのに正しく動作すると言い張られても嫌だし。

    > 1. 正しく動作すること
    > 3. テストできること

    → 正しく動作することを確認するテストがあること。

    もうすこし具体的に言うなら、こうかな。
      - すべての機能が自動化されたテストで正しく動作することを確認できること
      - 自動化されたテストを現実的なコストで追加できるように関数・モジュール設計をしていること

  • by Anonymous Coward on 2015年03月29日 20時36分 (#2786985)

    自分が最近見たやつだと、pcsensorのCソース。これは酷かった。
    Raspberry Piで常時温度計測しようと思ってRDing Temper買ってきて、Linuxから使おうとGithubからpcsensor落としてきたら、あまりの酷さに絶句した。
    ただ落としてきてビルドするだけだったら気づかなかったんだろうけど、libusbの0.1系に依存して書かれてるから1.0系に書き直そうかと思って中見たら・・・。

    あれは本当に凄いよ。
    たった1ファイル。それもたった450行のソースでありながら、リファクタしようという気力を根刮ぎ圧し折られるほどの圧倒的コーディング。
    一体どのような精神状態の元、あんなコードを書き上げられたんだろうと逆に興味が湧いてくるほど。

    • by Anonymous Coward

      ”pcsensor github"でぐぐって [google.co.jp]出てきたの見たけど別にぜんぜん大したことないなあ。おれならもっと酷いコード平気で書ける自信あるわ。

    • by Anonymous Coward

      ざっと見た限り、初見でも何やってるのかわかる読みやすいコードだと感じましたが、どの辺りが酷いと感じたのか興味あります。
      一点 bsalirという変数の名前の意味がわからなかったのですが、salirがスペイン語で「出る」というような意味らしいのでだいたいそういう意味かと。

    • by Anonymous Coward

      (このツリーでクソコード自慢が始まる予感がする)

  • by Anonymous Coward on 2015年03月29日 21時49分 (#2787020)

    良いコードを書くためになによりまず必要なのは、良いプログラミング言語を使うこと。
    良い言語で書かなければ、良いコードを模索しても徒労に終わる。
    クソ言語で良いコードを目指すというのは、犬のクソを美味しい料理に調理する方法を考えるようなものだ。
    まずは良い言語を選び良いフレームワークを選ぶ。話はそれからだ。
    クソ言語を使わざるをえない状況なら、少しでも良いコードを目指すことがまったくの無駄だとは言わないけど、
    その努力を他に振り向けたほうがはるかに幸せになれる

    • by Anonymous Coward

      1~8が実践できないプログラム言語があると言っているのか、
      あるいは、1~8のリストに追加する項目があるのかどちらでしょうか?

      後者だとした場合、どういった特徴の言語仕様、あるいはフレームワークを使うべきなのでしょうか。

      • by Anonymous Coward

        どっちでもないよ。
        「少しでも良いコードを目指すことがまったくの無駄だとは言わない」って言ったように、どんな言語でも良いコードを目指す余地はあり、
        当然「1~8が実践できないプログラム言語がある」などということにはならない。
        それに「1~8のリストに追加する項目がある」なんてことは俺はまったく言っていないな。
        俺はそのどちらかの話をしてるとなぜあなたが思ったのか、さっぱりわからない。

    • by Anonymous Coward

      コード以前に人生の無駄だからね
      PHPとかPHPとか

  • by HomuraAkemi (46038) on 2015年03月30日 13時14分 (#2787380) 日記

    客のために仕事をしようとすると、納品と検収がゴールになり、それに至るまでがやっつけ仕事になってしまう。
    自分のために創作すると、過程を重視するし、完成度をより高めようという意欲が湧く。作品への愛着も高まる。
    その結果、高品質なものができる。

    経験上、客を満足させようとすると、ろくなものができない。自分を満足させようとすると良いものができる。

    「自分さえ満足してしまえばそれでおしまい」というのは、悪い自己満足だ。だけど、自己満足の全てが悪だとは思わない。

    自分ひとりさえ満足させられないものを、客に提供するのは、職人として不誠実なことだ。
    ソフトウェアに限らず、多くの分野の職人にも当てはまるのではないだろうか。
    自分に自信がありませんというシェフの作った料理を誰が食べたいと思うだろうか。

    自己満足がゴールではなく、それは通過点であり、「自己満足は大勢満足の必要条件」だという発想をもてば、
    良いものができる可能性が開ける。

  • by kentok (41940) on 2015年03月30日 21時09分 (#2787759)

    懐かしいですね、
    MSX-FAN。

    あれでプログラムの本質を分かった気がします。

    --
    -- 風は東京に吹いているか
  • こんだけコメント付きながら、こういう脱線がないところにみんなの疲労感が見て取れるというか :-)
    #若手によいコードを書かせるのに苦労してる年寄りばかりになったともいう

  • by Anonymous Coward on 2015年03月29日 19時32分 (#2786946)

    正しく動くことは最低限の目標です。しかし開発期間中のほとんどにおいて当面の目標となります。

  • by Anonymous Coward on 2015年03月29日 20時43分 (#2786992)

    自分の名前を書かない。
    ・・たぶん良い事だ。(嘘)

  • by Anonymous Coward on 2015年03月29日 20時57分 (#2787006)

    ・一貫したルールが適用されていること。一部分でしか適用されないルールとか、部分によってルールの目的は同じなのに、異なるルールが適用されてたりしないこと。
    ・不必要なオリジナリティが無いこと。オリジナリティは、それが無ければプロダクトの優位性が失われる、という場面に限り、存分に発揮すること。それ以外のシーンでは、多少枯れた、標準的な手法に愚直なほどに忠実であること。

  • by Anonymous Coward on 2015年03月29日 21時31分 (#2787015)

    書く前にCode completeと達人プログラマ読ませて。
    言語特有のコーディングルールの本5冊読ませればいいんじゃね

typodupeerror

あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall

読み込み中...