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

コーディング標準は役に立つのか 154

ストーリー by headless
標準 部門より
本家/.「Ask Slashdot: Do Coding Standards Make a Difference?」より

私がこれまで勤めた職場はすべて、「キャメルケースを使うか、アンダースコアで区切るか」「中かっこの配置」「タブを使うか、スペースを使うか」といったコーディングスタイルのドキュメントが用意されていた。しかし、アルゴリズムをレビューせずにスペースの使い方を指摘するような人のがいるせいで、コードレビューのために数百時間を無駄にしてきた。実際のところ、このようなコーディング標準を適用することで生産性が上がることを裏付ける資料や研究があるのだろうか。そうでないとしたら、なぜこれらが必要なのだろう。いまどき、決められたコーディング標準を自動的にツールが適用してくれてもよさそうなものだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • >「キャメルケースを使うか、アンダースコアで区切るか」「中かっこの配置」「タブを使うか、スペースを使うか」といったコーディングスタイルのドキュメントが用意されていた。
    じゃ、読みましょう。適用しましょう。

    前提となるドキュメントを読んでいないようなのに、レビューしてもしょうがありません。
    あなたの時間はたしかに無駄になりますが、レビューした場合あなた以外の人が無駄になる可能性があります。

    私はEclipse派ですが、自動生成する際のコーディングスタイルを設定できます。
    自動生成できない部分に関しては、標準化する際に議論を行い、できるだけ自動化する、または採算が合わないようなら標準化適用外にしてます。

    #標準化って生産性よりも、保守性をあげてるんじゃないの?

    • by Anonymous Coward on 2012年12月24日 12時29分 (#2295464)

      そういえば、Eclipseのスタイル設定では設定できないスタイルをわざわざ設定してきた意地の悪い発注元があったなあ。ケチをつけてコーディング品質が低いとアヤをかけて、工数単価を事後に値切ったり、仕様変更の追加工数をロハにしようとしたりするひどい発注元でした。

      個人的には、識別子の命名規則以外は、レビュー前にindentコマンドで一括整形でいいのではないかと思ってます。

      親コメント
    • その通りですね.
      理由なく標準化を守らないのであれば,
      それはレビューに対する障害でしょう.

      標準化されてないコード箇所があれば,
      そこは「怪しいコード」である可能性が高く,
      「ここについてフォーカスしてくれ」という指定でもなければ,
      レビュー時に最も力を入れるべき箇所です.

      また, 標準化を無視するのであれば,
      その理由をレビュー時に明確にすればいいだけです.
      それは「この標準は生産性を下げる」と問題提起する機会にもなりますし.

      親コメント
    • 同じく、EclipseのプラグインでCheckStyleも使ってます。
      自動的にチェックしてくれますよね。

      Java以外でも使えたような?(言語によるけど)

      もし社内独特のコーディング規約が多すぎると
      反発おきて守ってくれない人多くなるかもしれませんね。

      キャメルが規約となっている中で、アンダースコアばっかり使うソースは読みにくいので、そろえるのはある程度意味ありますね。
      システムハンガリアン+単語の区切りがアンダースコアのソースとかやる気失せる。

      親コメント
  • たとえば、文章の校正をする場合を考えると、文字が汚な過ぎると読み取るのに苦労して、内容のチェックどころではないでしょう。文字のきれい汚いは文章の内容とは関係ないはずですけど。

    プログラムの場合も同じであり、にコーディングスタイルがいい加減だったり、変数名・関数名が内容とマッチしていなかったりした場合は、そちらの読解にばかりエネルギーが割かれて、プログラムの内容どころではなくなってしまうのでは無いでしょうか。

    • by Anonymous Coward on 2012年12月24日 13時36分 (#2295506)

      目立つノイズが消えると、本当の問題が見えてくる。

      同意です。学生がもってきた英語の論文の原稿なおすときは、最初の1回の修正は、ほとんど「てにをは」的な修正ばかりです。まずはこれ直してまたもってこいと(または、言いたいことと意味が違ってしまった箇所があったら、別の表現を再提案しろと)。そういう修正だけで真っ赤になって読みにくいというのもありますし、学生の頭を整理させるのにも役立ちます。その後で、論理的な構成について本人の書きたかった事を確認しながら修正する作業に入ります。

      親コメント
    • >文字が汚な過ぎると読み取るのに苦労して、

      その例えば不適切だ。
      #そもそも「文字の綺麗汚い」の問題は、ディスプレイで表示するに白プリンタで
      #打ち出すにしろプログラムでは通常起こらない。

      たとえば縦書きか横書きか、
      ノートはB罫かA罫かはたまた原稿用紙か、
      紙面の大きさはA4かB5か。
      或いは電子データにする場合はプレーンテキストなのかMSワードなのか。

      そういったことはなるべくなら統一されてる方が良い。

      特にたとえば小説/ラノベの新人賞に投稿してくるなら、どの形式で提出しろと定めていてもおかしくはない。
      出版を前提にしたプロの場合は、印刷に対応できるフォーマットであることは重要だろう。
      また同じ社内で利用する書類なら、同じ報告書のフォーマットが定められているのは普通だろう。

      しかし人間の可読性という点においては、それらはほとんど意味のない、どうでもいい話だ。

      親コメント
  • > 「キャメルケースを使うか、アンダースコアで区切るか」

    アンダースコア区切りはキャメルケースに対して「snake case」ですかね

  • by Anonymous Coward on 2012年12月24日 12時49分 (#2295472)

    C に記述標準を設けてバグの入りにくいコードを書けるようにという志で作られた MISRA C ですが、
    関数の末尾以外の return を禁止するという誰得ルールを筆頭に使い物にならない制約が多すぎます。
    役に立つところといえば、これをそのまま採用するところの技術力は信用できないという判断材料になることぐらい。

    • Re:MISRA C という失敗 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2012年12月24日 13時08分 (#2295484)

      > 関数の末尾以外の return を禁止する

      なぜ禁止なのかわからない人にコードは書かせたくないなあ

      親コメント
      • by Anonymous Coward on 2012年12月24日 14時06分 (#2295516)

        >> 関数の末尾以外の return を禁止する
        >
        >なぜ禁止なのかわからない人にコードは書かせたくないなあ

        この人深いネストが連なった山脈みたいなコードを書いてそう。
        そんなコードはフルHDモニタが普及した今でも読みたかないよ。

        親コメント
      • by Anonymous Coward on 2012年12月25日 2時15分 (#2295811)

        なぜ禁止なのか書いていないから「そのコーディング規約」はダメなんです。
        ルールが独り歩きする原因です。
        わかりましたか?

        親コメント
      • by nim (10479) on 2012年12月25日 9時18分 (#2295848)

        禁止の理由はよくわからないんだけど、
        関数途中で抜けたいときには Exception を上げればいいということですよね。
        そんで呼び出し元で処理する。

        親コメント
    • by Anonymous Coward on 2012年12月24日 13時26分 (#2295497)

      最低辺のレベルを確保することでリスクを低下させることを目的としているんでしょうね。
      禁止しないことによるメリットも比較検討してほしいところですが、ルールを決める(させる)動機がある奴は
      分かってない奴(が対象)なので期待薄。

      ツールとか技術レベルの底上げとか状況に応じて改訂していって欲しいけど、「障害事例を
      フィードバックしました!」とかいって肥大化するだけだったり。

      頭のいい人が言語を作る → 普通の人が頑張って勉強する → 理解できなかった人がルールを作る
      こんな感じに思える。

      親コメント
    • by dalzou9 (39752) on 2012年12月25日 12時24分 (#2295927)

      このまま採用というのはMISRA-C の使い方を誤っています。
      よくある誤解なのですが、MISRA-C ルールは禁止事項を整備したものではありません。
      MISRA-C ルールから逸脱することは想定されており、そのための手続き方法についても
      「MISRA-C 2004 C言語利用の高信頼化ガイド」(ISBN4-542-50346-1) の
      4.5 で延べられています。

      手続きをとらせることで、その逸脱したコードには本で述べられているような
      問題点がないことを再確認してもらうことが、本来のMISRA-C の使い方になります。

      親コメント
  • 問題はExcel設計書のコーディング規約だ。
    自動化もできないし、折り返し禁止だと推敲効率ガタ落ちになるし、とどめに明文化されていない俺様ルールが多すぎる。

  • ここまでで誰も具体的な数字データを上げないな。
    僕も持っていないからよくわかんないけど。

    思うに、自動整形ツールで直せるぐらいの範囲だったら、その規約は意味をなしていないように思える。
    ツールで修正してしまえばいい。

    例:インデントの幅、if (){ の {の位置とか。
    変数名やメソッド名も置換ツールでどうにかなるだろう。

    逆にツールで直せない問題こそ、
    人間が注意するべきところだろうと思う。
    これこそ規約で目標値を定めればいいと思うな。

    例:長すぎる関数、でかいループ(whileが1000行あるとか)、でかすぎるクラス(多すぎるメンバ変数)、深すぎる継承
    グローバル変数と化したsingleton、テスト不足とか。

    --
    by rti.
  • by Anonymous Coward on 2012年12月24日 15時47分 (#2295564)

    THE reaSON WHy coDiNg standards_exist is thatTheyIncrease THE_REaDABILITY oF YOur cODe.

    http://ask.slashdot.org/comments.pl?sid=3333189&cid=42363115 [slashdot.org]

  • ここのやり取り見てるだけでもコーディング標準は軋轢を生み、それを解決するためのコストが大きすぎると思った

    口先では標準大事と言いながらも、本音は自分の好きな書き方を標準にしたいだけでしょ?

typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...