ページ内ジャンプ:

アレゲなニュースと雑談サイト

hylomによる 2009年11月19日 12時00分の掲載
まずはコメントの書き方を教えるべき?部門より。

あるAnonymous Coward 曰く、

本家「If the Comments Are Ugly, the Code Is Ugly」より。

Esther Schindler氏は自身のブログでソースコードとコメントの関係について次のように書いている。「オープンソース好きでプログラミングに携わっている者だろうが、生活のためにコードを書いている者だろうが、プログラミングが細やかな注意力が必要な作業であることには変わりない。ソフトウエアを書いている者は重箱の隅をつつくような細かさがなければ動くコードは書けない。コメントに言い訳まがいのくどい説明などが書いてあれば、その開発者は恐らく自分の書いているコードをきちんと把握していなかったに違いない。」

コメントはそのソースコードを表すだろうか?例えばコメントに文法上の間違いが見受けられる場合、コードにも重大なエラーが潜んでいるものだろうか?

/.Jerの経験ではいかがだろうか?

表示オプション しきい値:
  • baku3393 (32616) : 2009年11月19日 12時15分 (#1674993) 日記
    「Ugly」の解釈がプログラマーと非プログラマーで異なると思います。

    文法が正確で誤字の少ない簡潔なコメントが書けても、そもそもクラス名とかメソッド名とか変数名
    が非直観的だったり、インデントが深すぎだったりしたら「コード」としては「Ugly」です。

    あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。
    バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。

    逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば
    「美しい」コードだったりします。

    むしろプアでしゃくし定規な「コーディング規約」なる法典をおしつけられて無理やりコメントを
    書かされていると冗長な説明文が入った「見た目にキタナイ」ソースになっちゃったりします。

    コメントもコードも「言語」ですからね。

    #ってか、「非プログラマ」な人種はソースなんて見るのか?(<俺)
    --
    ---- ばくさん!@一応IT土方
    • Anonymous Coward : 2009年11月19日 13時56分 (#1675080)

      > 逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば
      > 「美しい」コードだったりします。

      内容は賛成ですが、万人にはお勧めできないと思います。
      「自称」やり手プログラマの中には、
      コメントがなければ美しいコードだと勘違いしている人がいるようなので。

      以前、ソースコードにコメントがなくて理解できないことを書いた本人に言うと、
      「コメントがなくてもわかりやすく書いてある」
      と言っていたのですが、そのソースコードの不具合改修をお願いすると
      「書いてから時間が経っていてプログラムを解析する必要があるので、修正するには時間がかかる」
      と言ってました。
      そのためのコメントじゃないの?

      同様に「プログラマならemacsだろ!IDEなんか必要ない!」みたいな考え方の人もどうかと思います。

    • >> あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。
      >> バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。

      >ケースバイケースですが、これはちょっと断定しちゃうのは反対。
      >修正後のコードに問題が無いかの検証をするのに残すべき、という場合もあります。

      十数年前だったら、それも一利あったかもしれない。
      当時でも否定する意見は多かったけど。

      今だとこれはバージョン管理システム&バグトラッキングシステムで行うべきもの。
      未だにそれを導入してない/導入したけど使ってないというのは、バカがすること。

      「日本ではバカが非常に多い」という点については、残念ながらその通りというほかない。

    • Anonymous Coward : 2009年11月19日 13時11分 (#1675038)
      > 技術者って皆、口をそろえて「XXX使えばわかる」って言うのよね。
      > それって「ツールを使わなきゃ差分すらわからない」と同義でしょ。
      > ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。

      ツールを使いたくないのであればプログラマーとかIT業界にいないで転職した方が良いと思います。

      IT業界で「ツールを知らない」「ツールを使えない」「ツールを使おうという意欲がない」というのは
      ある意味決定的な問題です。自分にとっても周りにとっても。
      対人恐怖症の人がカウンセラーやっているのと同じぐらい悲劇です。

      IT業界人は前向きにメンドクサガリでないと:-)

      > そうやって自力で管理することを放棄して、作成者にしか理解できないソースばかり生み出すのよね。
      > あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。

      それはツールと関係ないのでは?
      気持はお察ししますが。
    • Anonymous Coward : 2009年11月19日 13時23分 (#1675049)

      えー・・・ネタだよね? 一応突っ込んどくけど、

      技術者って皆、口をそろえて「XXX使えばわかる」って言うのよね。
      それって「ツールを使わなきゃ差分すらわからない」と同義でしょ。
      ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。

      「共有フォルダに最新ソースがあります。修正前後の差分はコメントを見れば判ります。」
      と言われて引き継いだら、src_20091117 と src_最新版 と src_最新 フォルダがあったらどうしますか?
      ついでに、コメントは基本的に適当デタラメだったらどうしますか?

      そうやって自力で管理することを放棄して、作成者にしか理解できないソースばかり生み出すのよね。
      あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。

      バージョン管理システムやバグ管理システムは、作成者が更新しますが、最終的に管理者が管理するものですよ。
      管理者の人が管理しなかったら、作成者にしかわからない状態になりますが、それは自業自得ですね。

      # ちなみに全部実話です(涙

    • Anonymous Coward : 2009年11月19日 14時17分 (#1675108)

      ・diffを使うのはずるい
      ・それは実力ではない
      ・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。
      ・ツールを使うのはズルとしているのを同じ
      ということでしょうか [okwave.jp]

    • SigZ (37) : 2009年11月19日 18時01分 (#1675327)
      > あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。

      前の業者が逃げたあとの尻拭いをしたことがあります。つか、継続中だけど。
      当然、そんな奴らの書いたコメントが当てになるはずがありませんので、邪魔な先入観を与えるだけのコメントなら、ないほうがマシという状況です。
      正直

      # ○○な処理。。。なんだけど、うまく動かない。

      ってコメントには怒りを通り越して笑うしかない(笑)

      詳細なコメントは、それ自体へのメンテナンスコストがかかるので、コメントが不要なくらいに理解しやすいコードを書くというほうに努力すべきだと思います。
      # 昔 Linux-Users-ML でそんなスレッドがありましたよね。

      • firewheel (31280) : 2009年11月19日 20時51分 (#1675460)

        元コメじゃないけど、

        >コメントを信用しないってことは、関数名や変数名まで信用してないんでしょうか?
        もちろんです。

        >setなのに値を取得していて、getなのに値を設定しているじゃないかとか疑ってたら仕事になんない。
        その通りです。
        「下手なプログラマは存在自体が殺人的である」という事実を理解して頂けて幸いです。

        他にもgetなのに副作用があったり、勝手に内部でカウントアップしたりくらいは日常茶飯事。
        なんとかmanagerとかなんとかControllerって書いてあるけど、何をどのように管理するのか
        サッパリわからないとかもよくありますね。
        http://www.radiumsoftware.com/0603.html#060330 [radiumsoftware.com]

      • shuichi (572) : 2009年11月19日 21時14分 (#1675487) ホームページ 日記

        コメントを信用しないってことは、関数名や変数名まで信用してないんでしょうか?

        うん、基本的に信用していない。

        setなのに値を取得していて、getなのに値を設定しているじゃないかとか疑ってたら仕事になんない。

        get~()って関数が値を設定していることはザラだし、isFoo()って関数が予想とは逆の値を返すこともよくある。

        自分の書いたコード以外は信用できないし、自分の書いたコードはもっと信用できない。

      • 1個のコメント が現在のしきい値以下です。
    • 3個のコメント が現在のしきい値以下です。
  • クオリティは一致する (スコア:4, すばらしい洞察)

    Anonymous Coward : 2009年11月19日 12時16分 (#1674995)

    コメントと実装がずれていた場合、設計書の内容も最新仕様と一致していない。
    という事で、プロジェクトの管理自体がうまく回っていない。・・・ケースが多い。

    個人的な経験では100%。

  • Anonymous Coward : 2009年11月19日 12時20分 (#1674998)
    コードの表現できる範囲と、コメントの表現できる範囲は異なる。
    なので、それらを総合的に合わせて一番適切な表現になる様にするのがベスト。

    なぜそのコードが選ばれたのか?の意図はコードには表れない。
    コードは自分が何かは表わすけど、それだけ。選択の意図するものが
    最善なのか次善なのか、それともやっつけなのかわざとなのかはコードの記述範疇外だから。
  • Anonymous Coward : 2009年11月19日 12時39分 (#1675014)
    >言い訳まがいのくどい説明など

    精度の低いコードを書く奴って、レビューで指摘してもウダウダ言い訳することが多いのは実感としてある。
    仕様を理解した上での解釈の間違いであれば、指摘すればすぐに納得してもらえるし修正も早い。
    また、「意味がわかんねーよ」とキレるのは、少なくとも「わかってない」という現実と対峙しているのでいいほう。
    たちが悪いのは根本的に理解が不足しているのにそれを自覚していない奴。
    概要レベルの仕様の解釈で屁理屈をコネ回す奴は、プロジェクトから外すのが正解。
    コードレビューの次元でそもそも論とか持ち出す奴は敬遠したほうがいい。

    ついでに過去の経験から言うと、変数名などの命名規約を独自解釈する奴は危険。
  • 経験あり (スコア:2, 参考になる)

    Anonymous Coward : 2009年11月19日 12時14分 (#1674990)

    自信がないことを示すキーワードがある箇所は全部バグでした。
    (なぜか,とりあえず,苦肉の策,うまく)

    また、仕様書の曖昧なテキストがそのままコードコメントに貼り付けてあって、これもバグでした。
    (日本語の論理演算「または・かつ」と否定演算「ではない」の組み合わせ。人によって解釈がまちまち)

    ただ、コメントからのあら捜しは、かならずしもコードバグとは結びつかないので、絶対的なものではないですね。
    納品前に妙なコメントは除去されることもあり、そうなるとその痕跡は消えますし。

  • 自分の書いたソース? (スコア:2, おもしろおかしい)

    Anonymous Coward : 2009年11月19日 13時24分 (#1675050)

    ノーコメントです。

  • *個のコメントが現在のしきい値以下です。
    と、モデレート機能をソースレビュー時に付ければ良いのでは?
    あ、、、ソースも見れないや!コンパイルも げふんげふん。。。
  • Tellur52 (36331) : 2009年11月20日 0時49分 (#1675645) 日記

    これは、私が昔体験した話です。

    メールを読むのにUNIXマシンにログインするのが当たり前だった頃、主に使っていたメーラーがMHでした。

    あるとき、MHの仕組みが気になって、ソースを追いかけ始めたのです。まあ、その頃もメールの流量に辟易していたから、incあたりから読み進めたんだろうと思います。

    程なく、MHの核心部分のライブラリに近づいたのですが、あるファイルを開いてびっくりしました。
    そのファイルは妙にサイズが大きく、中はおぞましいVAXのアセンブリ言語が散りばめられているのです。Cの部分も他のファイルとは雰囲気が全く違います。

    「これは古代の遺跡に当たってしまったかもしれない」

    と思いつつ、ふとコードの先頭のほうにある長いコメントを見ると、中ほどに恐ろしい文句が書いてあったのです。

    > If you hack on this and slow it down, I, my children and my
    > children's children will curse you.
    意訳:「コードいじり損ねたら、末代まで祟ってやる」

    「えー、なにふざけた事書いているんだこの野郎」と思いつつコードのメンテナの名前を見ると、

    Van Jacobson

    とあります。

    え、何、このchildrenって人間じゃなくてパケット、と思った瞬間、戦慄が走りました。まるで、インターネットの深遠にある暗がりに潜む宇宙的恐怖を見たような。

    それ以後、私は「MHのコードだけは決して触らない」と固く誓ったのでした。

    今でもRand社由来のMH(たぶん6.8.4など)はどこかのLinux系ディストリビューションなどでパッケージとして転がっていて、Van Jacobsonの呪詛もソースパッケージの中でそのまま保存されているようです。
    コードを紐解いていけばすぐに出会えるでしょうが、古いUNIXのコードですから、横着して

    grep curse *

    とやってはいけません。恐らく数多の呪いが貴方を襲うことでしょう。

  • コメントの例 (スコア:1, おもしろおかしい)

    Anonymous Coward : 2009年11月19日 12時19分 (#1674997)
    char buff[MAX_SIZE + 100] // とりあえずちょっと多めに
    InitNNN(0, 0, 1, 0); // よく分からんけど参考例をコピペ
    h = WinInitialize(opt); // おまじない

    とかやったことあります。
  • コメントねえ (スコア:1, 参考になる)

    Anonymous Coward : 2009年11月19日 13時19分 (#1675045)

    コメントをどうこう言う暇があったらそんなもん全部消して実際のコードに注力しろよ。

    あ、そういえばこんな話題が。
    http://blogs.itmedia.co.jp/morisaki/2009/11/post-8f5d.html [itmedia.co.jp]

  • s02222 (20350) : 2009年11月19日 13時58分 (#1675082)
    > コメントに言い訳まがいのくどい説明

    出来る限りの最適化を加えてた結果としてどうしょうもなく読みにくくなって、それを緩和すべくくどい説明を添えることぐらいは許してください。

    単純なところでは、

    strcpy(dst + a + b + c, src); // 意図はstrcat(dst, src); ここまでの処理でstrlen(dst) == a + b + cなので

    みたいな、(この例だと変数名が最悪なのは置いといて)分かってる値を使い回してステップ数を減らすところから、もっと凝りに凝った最適化まで。

    ぱっと見て何が書いてあるのか分からない、と言う問題までは共通ですが、そういう場合に「じゃあどういう風に見て回ればその最適化で正しいと確かめられるか」のメモを残すよう心がけています。

    最適化しなくてもいいような場所は、そんなことよりロジック・ソースを分かりやすくて無駄に長いコメントを付けなくていいようにすべきですが。
    # argvの解釈を1ステップでも速くしようと血道を上げる最適化厨だった青春時代
    • Re:良い言い訳 (スコア:2, 参考になる)

      okky (2487) : 2009年11月19日 15時20分 (#1675177) ホームページ 日記

      うしろから羽交い絞めにして、
      「やめろ、やめるんだ!!」
      「はなせっ離してくれっっ、ここを最適化しないと…ここを最適化しないとっっ」
      「ばかっ、そこで苦労してどうする。今じゃもう、gcc とかの最適化がそんな事は全部やってくれるんだっっ」
      「な…なんだって… じゃぁ、俺の今までの苦労は…」

      うん。もう同情に涙が止まりませんよ。gccの最適化の強靭さを見た瞬間の感動を君にも分けてあげたい。

      .

      ただ、そのためにコードを読みにくくするのは昔のコードであってもお勧めできません。

      「アセンブラで組め」
      「インライン アセンブリコードで組め」

      で、コメントにCの読みやすいコードを書くんだ。
      「いつか、良いコンパイラが出てきたら、このアセンブリコードは破棄するように」
      というコメントをつけて。

      --
      fjの教祖様
      • Re:良い言い訳 (スコア:3, おもしろおかしい)

        Anonymous Coward : 2009年11月19日 16時37分 (#1675249)
        「そんなことはコンパイラがやる」
        「コンパイラなんかアテにならない」

        こういう小競り合いはしばしば見かけるが
        毎回共通していることがある

        どちらもコンパイラの出力を見ていない
      • 1個のコメント が現在のしきい値以下です。
  • プログラミング能力と国語力は無関係だと思います

    #日本語BASICの「ぴゅう太」ですら
  • コメントに

    /* ○○の例外だにょ */

    とか書きたがる馬鹿どもはそろそろ絶滅してくれたんでしょうか?

  • むかし、マクダネル・ダグラスから届いた仕様書を読んでいて。

    「すいません。ココ、意味が不明ですが、説明ください」
    と質問すると
    「あー。そこは設計者が仕様を理解していないんで」
    と返ってきたな。
    ※英文の仕様書です。
    ※軍関係の仕事ではありません。

    仕様を理解してなくてどうやって設計するのだろう。

    で、本題にもどると。
    たまーに、他人の書いたソースコードのメンテで、上のような事態があります。
    コメントに「よくわからないがとりあえずうごくのでこういうコードになってます」
    って書いてあったり。
  • hohehohe (11394) : 2009年11月20日 1時18分 (#1675665)
    俺はコメントに言い訳まがいのくどい説明など書かない。

    //webからコピペ、よくわからない
    template < typename T >
    ...

    //-1にしたら動いた
    for (int i = -1; i < maxloop; ++i)
    ...

    //3って何?
    result = func(3);
    ...

    //-符号は帳尻合わせ、駄目なら外せ
    bb = -func(aa);...
    ...

    //まだバグあり
    ...
    --
    AVG anti-virus data base out of date
  • Re:コメント抽出 (スコア:2, すばらしい洞察)

    Anonymous Coward : 2009年11月19日 12時24分 (#1675003)
    コードだけ読んで「何をしたいプログラムなのか」意図のわかるコードになっていて欲しいなあ。
  • Anonymous Coward : 2009年11月19日 13時04分 (#1675033)

    そうなんだけどね、

    有名な開発者がそれをやってくれちゃうと、もう俺のような凡人が触るなんて怖くてできないよ。
    書き換えて「なんとかしてやったぜ!」なんて言っちゃうと、
    山のように「お前のコードの正当性を説明しろ」「これこれこういう場合は考慮したのか」とか
    文句がやってくるんだぜ。しかも英語か英語みたいなので。
    それに対して英語で反論なんてしてられねーよ。

  • reininn (35924) : 2009年11月19日 13時59分 (#1675085)
    コメントを抽出してドキュメントを自動生成する怪しいソフト
    が、その昔ありました。
    それで、生成された意味不明のドキュメントを納品された私は
    思わず、ぶっ飛びそうになったとさ。
  • 1回だけ, AVL木のコーディングをした時にコードの横に対応する木の変形をAAで書いたことがあります.

    本当はglobal [gnu.org]みたいな感じで, コード中に対応する設計ドキュメントへのアンカーを埋め込めれば便利なんでしょうけど.

  • /* ここはよく分からないが、問題ないので残す by後任 */ ←言い訳まがいのくどい説明
            int i = 0;
            i = i + 1;

            if(i == 1){
                    i = i - 1;
            }
            else{
                    i = i + 1;
            }

            /* 1 から 10 までの数字を "i = XX" の形式で表示する */ ←期待されるソースコードコメント
            for(i = 1; i = 10; i++){
                    printf("i=%d", i);
            }

  • もうひまわり [hima.chu.jp]とか使った方が早そう。
  • 昔はコードを書いてからコメントしてたが、今はコメント書いてからコードに変換してる。
    当然、アルゴリズムはコメントで説明し易いこと優先。

  • 12個のコメント が現在のしきい値以下です。