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

いいコーディング規約、悪いコーディング規約? 231

ストーリー by soara
とりあえず indent してみた 部門より

Anonymous Coward曰く、

本家Slashdotに聞け!「Best and Worst Coding Standards?」より

本格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基本的なガイドラインとして、gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたらcontinue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。
可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか? ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか?
/.J諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか? 逆に規約のせいで問題が起きてしまったケースなどあるだろうか? 他にも、使える「自分ルール」などもあれば是非。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • コメントで残す (スコア:5, おもしろおかしい)

    by yasu (7) on 2008年07月22日 21時13分 (#1388500) ホームページ

    「変更する場合には、変更前のコードを全てコメントで残して日付・変更者を記載すること。」
    バージョン管理システムを使おうよ…

    --
    HIRATA Yasuyuki
    • Re:コメントで残す (スコア:2, すばらしい洞察)

      by SteppingWind (2654) on 2008年07月22日 21時41分 (#1388530)

      これに一票. これに比べれば, どれほど変な規約でもかわいいものです.

      21世紀に入るまで, こんなバカ規約が存在することを知りませんでした. 私が会社を辞める原因になったと言っても過言ではありません. しかも巨大システム開発ほど, この規約を採用しているケースが多いので, 数兆円規模の損失の元になっているでしょう.

      親コメント
      • by Anonymous Coward on 2008年07月22日 21時59分 (#1388557)
        >これに比べれば

        「関数名は連番」に比べても、ですか?

        私は両方体験しましたが、どちらも許せませんでした。

        親コメント
        • Re:コメントで残す (スコア:2, おもしろおかしい)

          by Anonymous Coward on 2008年07月23日 12時11分 (#1388932)
          私が伝え聞いた中で一番酷かったのは、引数の使用を禁止し、値の受け渡しをグローバル変数で行うよう強制する規約ですね。
          # 理由は「引数を理解できない開発者がいるから」らしい
          親コメント
    • Re:コメントで残す (スコア:2, おもしろおかしい)

      by realloc (27431) on 2008年07月22日 22時04分 (#1388561)
      バージョン管理使ってるのにコメントで残してるところもありますよ。
      なんのためにバージョン管理使ってるんだかわからなくなります・・・。
      親コメント
      • by $ir (18994) on 2008年07月22日 22時46分 (#1388588)
        あぁ、今それだ。
        「バージョン管理使ってるんだからコメント履歴止めましょう!」って何度かかけあったら廃止の方向に向かってくれた。
        親コメント
        • by Anonymous Coward on 2008年07月22日 23時09分 (#1388605)
          そういう奴らは、
          ソース「そのもの」はバックアップするが、
          バージョン管理のリポジトリはバックアップしない(するに値すると理解してない)
          という恐れがあるので気をつけるべしh。

          いちいちチェックアウトしたもの「を」バックアップするのね。まあなんというか、自動車を見て「手綱はどこだ」とか訊いたという古代人のようなもんだ。新しいツールの「根本」を理解してない。

          それはそうと。自衛策として、
          つまりもしリポジトリが飛んだら会社も困るが開発した自分らも(萎えるし仕事が増えるから)困るので、
          私はそういう場合は自分で勝手にバックアップすることにしてる。
          幸い最近は普通に安く買えて使えるローカルPCのHDDが余り気味であることが多いので、
          自分のPCのその余力でもって、リポジトリをバックアップしとくのだ。
          ついでにドキュメント"サーバ"のバックアップも同様に"クライアントPC"に取っておくのがお勧めだ。
          奴らのバックアップなんて信頼できん。「過去1週間だけ残してあればいい」なんて平気で言う奴らだからな。(それって2週間前に人知れず起こったデータ破壊には無力じゃん!)
          それにバックアップ自体が有ったとしても取りだしが容易ではない(手続きを要したりツールが煩雑だったり)可能性も警戒すべきだ。
          だったら自分とこでバックアップを走らせればいいんだ。もちろん使い易いツールを自分で選んでね。
          サーバとクライアントの関係が逆じゃないか!と思う人は頭が固い。使えるHDDなら猫のHDDだって使う。残存したファイルが官軍。それでいいんだ。
          あとクライアントはたいてい複数あるから、
          同じバックアップを複数のクライアントでやればそれだけで冗長性が確保できるぞ。
          親コメント
          • Re:コメントで残す (スコア:2, おもしろおかしい)

            by Anonymous Coward on 2008年07月23日 1時01分 (#1388685)
            奴らの仕事作成能力を甘く見てはいけません。
            そのうちセキュリティー対策でローカルHDDとUSB端子のないPCになりますよ。
            親コメント
  • 規約以前 (スコア:4, 興味深い)

    by Tsann (15931) on 2008年07月22日 22時43分 (#1388586)
    コンパイルが通ること。いやマジでいるんだよ。
    # あー、のど元まで愚痴が出かかってる。
    たとえコンパイルが通ってもエディタなどが解析できる程度に。Emacsのcc-modeとかね。
    # //形式の正規表現中にエスケープされない/が入ってて凹んだ。

    逆に、このレベルとなるとコンパイラの警告とかは読んでも理解できないから、警告を消せとは怖くて言えない。
    # 引数が足りないと言われるととりあえずnull突っ込まれたりする。
  • 逆に規約のせいで問題が起きてしまったケースなどあるだろうか?
    1. コーディングをした事が無い人(検査部門とか)が作った規約。
      実際にコーディングする人間からすると、意味不明なのがチラホラ。
    2. コーディング担当者のレベルに合っていない(バカさ加減を甘く見てる)。
      前任者が作ったプログラムを見ると、確かに、コーディング規約は守ってたが、暗黙の前提・常識は守って無かった……つまり、絵に描いたようなスパゲッティーコードだった、と。
    3. コーディング規約が出来たのが、プログラムの最初のバージョンが出来た後。
      既存のプログラムを改修しようとすると、エラい事に……。
    4. コーディング規約が守られているか、コードを全部プリントアウトして確認しろ、と言う規則になってた。
      殺意と言うのが、どんな時に湧くのか、良く判りました。
  • 燃料投下 (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2008年07月22日 22時09分 (#1388566)
    ・三項演算子は使わない
  • indent を使え (スコア:2, 参考になる)

    by okky (2487) on 2008年07月22日 21時37分 (#1388523) ホームページ 日記
    命名規則等はともかく、indent で直せる部分に関しては indent で直すようにするのがよいコーディング規則。
    --
    fjの教祖様
  • by Anonymous Coward on 2008年07月22日 22時02分 (#1388559)
    >逆に規約のせいで問題が起きてしまったケースなどあるだろうか?

    起きればまだいいんですけどね。タイトル参照orz

    一番判り易いところでいえば、
    「関数名やファイル名は連番!」とかね。

    名前の意味から、その参照先が何者なのかを、察することは不可能です。

    (暗記することは出来るかも知れないがね。ああいう現場では発想力より暗記力が強い奴のほうが幅を利かせる…orz)

    で、それに起因する「問題」ですが、
    彼ら(の老害重役どもだと思われるが)は
    それが好きでやってるわけだから、
    それで「問題」が出ても、無かったことにされます。

    無かったことにするのは簡単ですよ。
    「それよりマシな生産性」を観測しなければいいんですから。
    つまり普通のネーミングを絶対許さなければ、
    それ以上生産性が良くなるとどうなってしまうのか?を
    (心ある一部の人以外は)気づかず終わります。

    昔からそうでした。今もそうでした。私が知ってるだけで5年ですまないだけの時間、彼らはそうしています。きっともっと前からそうだったんでしょう。

    #某有名企業の内情なのでAC
    #それこそ隠れた損失は数兆円だったりしないだろうか…
  • by SaySet (18192) on 2008年07月22日 22時40分 (#1388585) 日記
    何をどう書けっていうサンプルとかもない(見ない)ので、テンプレートのまま放置してる奴。
    おかげでクラス名・メソッド名だけのjavadocができてきて、何の役にも立ちゃしないorz

    100万歩ゆずって、一般の開発部隊の成果物がそうであっても許してあげようかなという気にもなるが、それが基盤・ツール部隊の作ってる汎用部品だったりするともうねぇ...

    やっぱ「規約」で縛るだけじゃなくって、「なぜそうしなければならないのか」をみっちり教え込まないとダメっすよ。>だれともなく。
  • はいつまでも古いままで使いにくいです。
    あとは、プロジェクト内でもコアな部分を作るチームと、
    それ以外のチームは分けて欲しいなと思ったりすることが多いです。
  • というのは半分ジョークということにしておいて、MISRAとかGNUの規約とか、それなりに実績のある規約を
    叩き台に実際にコーディングする人たちで膝突き合わせて話し合えばそこそこ現実的な規約になるかと。

    まあ実際は「客の規約に合わせます ホントにアレなとこだけ一応文句言ってみます」になりがちだけど。
  • by hide_gc8 (29498) on 2008年07月23日 3時30分 (#1388758)
    みなさん、それぞれに自論がおありのようですね。
    わたしもいくつかありますがなによりも重要なのは

    "規約を決めたなら徹底的に守らせること"

    たとえゆがんだ規約であっても、コーディングが確実に
    規約に則っていればある程度までは保守できます・・・と思いたい。
  • by Anonymous Coward on 2008年07月22日 14時45分 (#1388168)
    ×ガイドラン
    ○ガイドライン

    メンテ性(←推奨されない)
  • by Anonymous Coward on 2008年07月22日 20時26分 (#1388458)
    Google C++ Style Guide
      http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [googlecode.com]

    その訳
      http://www.henshi.net/k/hiki.cgi?GoogleCppStyleGuide [henshi.net]

    #C++のコーディング規約といえば、fool-proofに傾けてるのが多いよな・・・
  • ほとんど無い (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2008年07月22日 20時26分 (#1388459)
    ・コメントは書くように。
    ・インデントはTabで。
    ・テクニックに走らず、誰が見てもわかりそうな構文で。
    ・できるだけ省略しないで書いて。

    命名規則とかは、今の会社では無いですね。
    • Re:ほとんど無い (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2008年07月23日 0時52分 (#1388677)
      >・コメントは書くように。
      何をしているのか、ではなく、何故なのかを書けって教わりました。
      そのため関数の先頭にコメントをたくさん書くようになりました(if,for等のブロックを扱うレベルで言及はあるけど)

      仕事としてのプログラムを習いたての頃は"初期化する"とか後で訳のわからなくなるコメントが多かったので非常に勉強になりました。

      #大人になったら何をしてるのかはコードに書いてあるってよくわかるようになったよ
      親コメント
      • Re:ほとんど無い (スコア:2, 参考になる)

        by Anonymous Coward on 2008年07月23日 8時25分 (#1388809)
        >何故なのかを書けって教わりました。

        良い環境ですね。良い上司、良い先輩…

        悪い環境では「何を」を逐一書かないとレビュー通りませんから。
        ええ。わざわざレビューでもってコードを劣悪化してるわけです。これも損失数兆円?

        あと振る舞いばかり気にする連中も困る。
        つまり振る舞いにはコメント逐一入れさせるいっぽうで、
        変数にはコメントつけないのな。
        どっちかというと、変数に「これは何か」ってコメントをつけてくれると、
        そのあとのその変数の人生が想像できて、追い易いんだけどな。
        こういう、「人生を想像」みたいな一種の児戯っぽいものが、実は一番人間の脳にとっては易しくて、そのぶん便利なんだよ。
        親コメント
    • by parsley (5772) on 2008年07月22日 20時31分 (#1388467) 日記
      関数名の頭4文字ぐらいは縛られるけど、後ろが長くだけなのでそれほど不自由でもない。

      7文字制限なんて遠い昔だな。
      --
      Copyright (c) 2001-2014 Parsley, All rights reserved.
      親コメント
    • by Anonymous Coward on 2008年07月22日 21時56分 (#1388554)
      >・テクニックに走らず、誰が見てもわかりそうな構文で。

      何をもって「テクニックに走った」と呼ぶか?がまちまちなんで困るんですよね。

      例えばRuby畑(の外側)で時々聞く、「RubyのBlockは使わない。イテレータ使わない。for文でやる」という奴。

      私は、そんなことしたらRubyのうまみの8割が消し飛ぶ、
      (だってそれじゃVBと字面そっくりじゃん。だったら素直にVB使えよ)
      つまりRubyにBlockは「必須」だと思うのですが、
      あれを「テクニックだ。誰が見ても読めるってわけじゃないから却下」する人らも居るようです。

      #宝の持ち腐れだと思うぞー?
      #Rubyのうまみは突き詰めればリテラルだろ。正規表現リテラル、(埋め込みが出来る)文字列リテラル、Rangeリテラル、そして関数リテラルもどきのBlock、などなど。
      #あとはメタプログラム系かな。
      #OOPなんていまどき当たり前なので騒ぐだけ野暮。
      親コメント
      • by Anonymous Coward on 2008年07月23日 7時44分 (#1388795)
        元ACですが

        > 何をもって「テクニックに走った」と呼ぶか?がまちまちなんで困るんですよね。

        これには深い意味があって、
        ・周りのメンバの力量が計れない人は、チームを組んでもうまくやっていけない
        って所の裏返しです。

        先に上げた4つの規約も、大雑把にいえば「協調性・思いやりを持ちましょう」程度の事です。
        これが無いと、例えずば抜けた能力があってもうまくいかないです。
        親コメント
    • >・コメントは書くように。

      私のプログラムのコメントというかバージョン管理システムの更新履歴に
      全て「にょろーん」って書いてあるのは内緒です。

      当然ながら、誰にも公開してないプログラムですよ
      親コメント
    • by Anonymous Coward on 2008年07月22日 23時45分 (#1388633)
      >テクニックに走らず、誰が見てもわかりそうな構文で

      ここで紛糾するんだよね。C言語限定だと

      if(pointer==NULL||*pointer='\0')って書いて「NULLポインタを参照するなよ」っていわれるとか。
      「for(p = buf; *p; ++p)」って書いて「for(i = 0; i < strlen(buf); i++)にしろ」と怒られるとか。
      「sprintf(buf, "%*d", digits, num);」って書いて訳分からんと怒られるとか。

      3項演算子のことは知りません。
      親コメント
  • インデントはタブ文字。
    表示は4スペース。
    異論は認めない。

    #スタンドアローンな開発は楽だねぇ。
    --
    妖精哲学の三信
    「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
  • 色々あって整形以外の規約が上手くまもれてません@今の仕事。

    # 自分でもヒデェスパゲッティなコードだと思う。コメントしようがない所ばっかだしorz

    こればっかじゃアレなので。

    良い規約:書き易い、読み易い(意味の取りやすい)、改変し易い、間違い(スペルミスからアルゴリズムの間違いまで)が分り易い、そしてそのために合理的で無駄はない。

    といいな。とか思うのですが、現実はそこまでいきませんねぇ。

    # あと、規約にプログラムの構造に踏み込んだような記述がありますが、あれについては微妙かなとも思う...
    ## できぬおバカのワガママと自戒しておりまするぅ。
    --
    M-FalconSky (暑いか寒い)
  • ハードタブは8だけどインデントは4とかいうコーディングする者の面倒を考えないような場合は整形ツールを作って自動化しますね。
    簡単なのは秀丸マクロで出来るし、単なるスタイルなんて変換すればいいだけ。
    自分的に大事なのはgrepとかのツールで参照や使用を簡単に把握できたり、置換で一気に変えたりできること。
    その為にはクラス名と変数名のように関連のあるものは一貫性のある変換ルールにする方がよい。
    折角、自動化して生産性を向上し易い環境なのだから利用しない手はない。
    • Re:整形ツールを作ったり (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2008年07月22日 22時04分 (#1388560)
      自作の整形ツールを使ったら、知らぬ間にソースの一部が欠けている事に気がつきませんでした!
      と言ってみるテスト
      親コメント
      • これだけ一気に自動的に沢山変更するわけだからWinDiff等を使って間違ってないか確認したり、バージョン管理システムを使って戻せるようにするのはセットですね(^^;
        昔はC言語レベルの構文解析を行って関数単位でリスト構造に変換してソース生成を行うというスタイルコンバーターを作ったりしていました(^^;
        肝はコメントも構文の一部とすることでスタイルだけを変えられるようにしているところですが、たまに想定から外れたコメントが消えたりしたような気がします(^^;
        親コメント
  • Viewは使わない (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2008年07月23日 1時03分 (#1388688)
    以前参画したプロジェクトにて、DBの設計規約にありました。
typodupeerror

アレゲはアレゲを呼ぶ -- ある傍観者

読み込み中...