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

/.Jに聞け:コメントにおける変なルールって? 128

ストーリー by hylom
コメントは動作に影響がないからこそ好き勝手やり放題 部門より
insiderman 曰く、

ブログ「日々常々」で、「変更前をコメントアウトして残す」というバカバカしい習慣が紹介されている。

例として挙げられているのは、「コメントを削除する場合その旨をコメントとして残す」という例。

// 2012/08/15 irof 修正開始
//// 2012/07/21 削除開始
//// // 間違ったコメント
//// 2012/07/21 削除終了
// 2012/07/21 irof 削除開始
// // 間違ったコメント
// 2012/07/21 irof 削除終了
// 2012/08/15 irof 修正終了
someMethod(arg);

見るだけで笑えてしまうが、実際コメントに変更履歴を残す習慣が残っているところはまだ多いのでは? 有識者の皆様に、「変なコメントルール」をうかがいたいところである。

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

    by miyachi (13667) on 2012年08月16日 21時05分 (#2213538)

    退職してから4年振りに前職で8年間担当していたソースを見た。
    そこには…

    // このソースは不幸のソースです。
    // 関わった人は皆辞めて行きます

    別に私のせいではないけど後任が皆長続きしなかったらしい。
    え?やっぱり私のソースのせい?
    私のソースが駄目だから辞めた訳では無い…はず…orz

  • ばかだな (スコア:4, おもしろおかしい)

    by Anonymous Coward on 2012年08月16日 19時16分 (#2213475)

    行数増やした方が料金とれることもしらないのか?
    急いで対応したら特急料金な

  • by Anonymous Coward on 2012年08月16日 18時54分 (#2213460)

    まあ仕方ないと思わなくもなくもなくもないけど(VCS使っていない事自体がダメすぎてとっとと逃げる算段を計るけど)、VCS使ってまでソースをゴミで埋めたがるんだからマジで何やってるのか意味分からない。
    # いちおうソースコードの管理について意見を出せる立場だったので反対してみたけどダメだった

    • by Anonymous Coward on 2012年08月16日 19時27分 (#2213488)

      私も昔は今回のストーリーのような話を聞いたときは鼻で笑ってたものなのですが…

      今受けてるプロジェクトは、上の意向でSubversionで管理してるのですが、このストーリーのネタほどではないにしても、基本的に削除修正でも削除したことを示すコメントを半ば自主的に残してます。
      「仕様書では○○することになってる」ものを「口頭で△△にするように指示をうけ」たりしたときに、言質を取る意味が大きいですかね。
      あとで「動作が仕様通りの○○になってないんですけど」って言われたりするんだもん

      1行単位の修正ごとにコミットしていけば、コード上は削除してしまってもいいんだろうけど、
      「テスト済のコードしかコミットしちゃダメ」っていうので、ある程度まとめてコミットするしかない状況で…
      ファイル単位でしかログが残せないというのは、コミットログの粒度が荒すぎます。
      (「△△のため、削除」したところもあれば「△△にするため、□□を追加」したところもあったりして、それぞれ個別にコメントを残したい)

      親コメント
      • Re:Subversion使ってるけど (スコア:2, すばらしい洞察)

        by Anonymous Coward on 2012年08月16日 19時43分 (#2213499)

        まあ、別にいいんじゃないですかね。
        目的は「分かりやすくて運用しやすい」でしょうから、杓子定規にする必要はないと思います。
        とにかく全部残せ!は思考停止でナンセンスですが、とにかく残すな!も同様かと。

        親コメント
      • 仕様書改版させるべき。
        たとえソースにメモしてても「言った言わない」の範疇だし、受け入れテスト担当はそんなことは知らんから。

        で、コミットログだけど...diff取って該当部分に理由を書くとか、gitでやっといてsvnなブランチにマージするときcommitもコメントもまとめるとか...かなぁ...。

        親コメント
      • by Anonymous Coward

        修正した項目ごとに、行番号とか関数とかをログに書けば良いのでは?

    • by Anonymous Coward on 2012年08月16日 20時02分 (#2213511)

      VCSありかつコードのコメントアウト禁止というルールで開発をやってたことがありますが、
      どうしてもやってしまう人がいました。

      削除し忘れたと言うんですが、そもそもなんでコメントアウトしておくのかと聞いてみると、
      適当に修正してテストしてOKだったらcommitするというやり方をしているそうです。
      要するに原因を突き止めて対策を練ってから修正するのではなくて、行き当たりばったりなんですね。
      とりあえず、そういうやり方ならコードのコメントアウトは便利だと納得はしました。

      コメントの意味も含めてコードレビューをすれば、最終的にはコードのコメントアウトを削除できるはずです。
      このコードには意味があってとってあると言われたら、検証済みか/検証手順は整備されているか聞けば良いでしょう。
      レビューしないような環境なら好きなようにやらせてあげようよ。

      親コメント
  • いろいろとコメントがごちゃごちゃ書いてあるけど、結局なにがどうなって現時点でどうなっているのかがよくわからないコメントにお目にかかったことが何度かある。
    コメント内容から今どうなっているのかが分かるだけまだマシなのかも知れない。

    •  私が担当しているシステムには、下記のようにコメンがありますが、見事にXとYが入れ替わってるソースがあります。
      #しかも2か所同じようなものがあるが、片方は正しく書いてあるという・・・(笑)
      #元からコメントは参考程度にしかならない(画面コピーしかない設計書も役に立たないのでソース読め状態)ので誰も(私も含めて)コメントを書き換える人がいない(笑)

        Select Value
              Case 1 //X-Aです
              Case 2 //X-Bです
              Case 10 //Y-Aです
              Case 11 //Y-Bです
        End Select

      親コメント
  • by Anonymous Coward on 2012年08月16日 18時50分 (#2213455)

    どんなツールが便利か議論した方がいいでしょう。

  • そもそも (スコア:1, 荒らし)

    by keinear (45557) on 2012年08月16日 19時24分 (#2213485)

    この話がいったいどういうことなのか理解出来ない\(^o^)/
    誰かサッカーで例えてください。

    • by array (25012) on 2012年08月16日 20時50分 (#2213531) ホームページ

      ・反則したら、物理的にイエローカードをもらう。
      ・次の試合にでたら「あ、前のイエローカード、間違えたから」と言われつつも、そのイエローカードは持たされて、そのカードに「無効」と書かれる。
      ・で、また次の試合に出たら、「無効にしたの、間違ってた。やっぱりイエローね」とかいわれて、無効の文字が二重線とかで消される。無効の文字は読める。
      ・で、次の試合で反則して、イエロー出たんだけれど、いったい何枚累積しているのか誰もわからない。

      #かえってわかりにくい(^_^;

      親コメント
    • by Anonymous Coward on 2012年08月16日 19時43分 (#2213500)

      前の試合までに着たユニフォームを重ね着して試合に出るようなもの

      親コメント
  • ウチではアセンブリ的な要素が多い言語を使っている為、
    ソフト操作の指導に行く自分は修正を行う際に、
    「急な修正の際、電話で客に修正点をしてもらうので修正してもコメント行付与するな!」と厳命されています。

    明確な仕様の策定とデバッグしっかりしてれば電話修正(笑)なんて不要だと思うのですが、ホント滅茶苦茶です。
    --
    ----- ド素人につき突っ込み歓迎 アルミ製なので叩くと凹みます
  • x = 10;    /* x に 10 を代入 */
    if (a > 0) /* a が 0 より大きい場合 */
    {
    ....

    コードの内容はフィクションですが、ほぼ、こんな感じのソースを実際に見た。

  • by Anonymous Coward on 2012年08月17日 13時43分 (#2213881)

    ソースコードとの差分を渡して「正社員にチェックイン」してもらわないとならない環境ってのもあるんだよ。

  • by Anonymous Coward on 2012年08月16日 18時48分 (#2213453)

    「踏み逃げ禁止」とか系の話かと思ったら全然違った

  • by Anonymous Coward on 2012年08月16日 19時31分 (#2213492)
    修正日付と担当者名だけが記されているコメントの意味は、不具合があった際に「○○さーん、ここNGだってよー」と○○さんを呼び出すためのタグとしての機能。
    コーディングした本人じゃないと対処できないから。

    品質とか効率とか以前に、組織的に正常な業務体制が構築されていない証だね。
  • by Anonymous Coward on 2012年08月16日 19時31分 (#2213493)

    前いた研究室では、コメント文は変更前コード、テストコード、#defineスイッチ以外ほとんど見かけなかったよ

  • by Anonymous Coward on 2012年08月16日 19時47分 (#2213502)

    年号が2012ではなく、19XXの頃ならこういうのが多かったですね。
    ソースコード管理システム自体、あまり普及してませんでしたから。

    元記事にはないですが、修正担当者の名前も残します。

typodupeerror

日々是ハック也 -- あるハードコアバイナリアン

読み込み中...