コメントはソースコードを表す？ 161
ストーリー by hylom
まずはコメントの書き方を教えるべき？ 部門より
まずはコメントの書き方を教えるべき？ 部門より
あるAnonymous Coward 曰く、
本家「If the Comments Are Ugly, the Code Is Ugly」より。
Esther Schindler氏は自身のブログでソースコードとコメントの関係について次のように書いている。「オープンソース好きでプログラミングに携わっている者だろうが、生活のためにコードを書いている者だろうが、プログラミングが細やかな注意力が必要な作業であることには変わりない。ソフトウエアを書いている者は重箱の隅をつつくような細かさがなければ動くコードは書けない。コメントに言い訳まがいのくどい説明などが書いてあれば、その開発者は恐らく自分の書いているコードをきちんと把握していなかったに違いない。」
コメントはそのソースコードを表すだろうか？例えばコメントに文法上の間違いが見受けられる場合、コードにも重大なエラーが潜んでいるものだろうか？
/.Jerの経験ではいかがだろうか？
あんまし関係がないと思う (スコア:4, すばらしい洞察)
文法が正確で誤字の少ない簡潔なコメントが書けても、そもそもクラス名とかメソッド名とか変数名
が非直観的だったり、インデントが深すぎだったりしたら「コード」としては「Ugly」です。
あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。
バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば
「美しい」コードだったりします。
むしろプアでしゃくし定規な「コーディング規約」なる法典をおしつけられて無理やりコメントを
書かされていると冗長な説明文が入った「見た目にキタナイ」ソースになっちゃったりします。
コメントもコードも「言語」ですからね。
#ってか、「非プログラマ」な人種はソースなんて見るのか？(＜俺)
---- ばくさん！＠一応IT土方
Re:あんまし関係がないと思う (スコア:4, すばらしい洞察)
> 逆に、何にもコメントがなくてもコード自体が短くて直観的でコメント自体が不要なものであれば
> 「美しい」コードだったりします。
内容は賛成ですが、万人にはお勧めできないと思います。
「自称」やり手プログラマの中には、
コメントがなければ美しいコードだと勘違いしている人がいるようなので。
以前、ソースコードにコメントがなくて理解できないことを書いた本人に言うと、
「コメントがなくてもわかりやすく書いてある」
と言っていたのですが、そのソースコードの不具合改修をお願いすると
「書いてから時間が経っていてプログラムを解析する必要があるので、修正するには時間がかかる」
と言ってました。
そのためのコメントじゃないの？
同様に「プログラマならemacsだろ！IDEなんか必要ない！」みたいな考え方の人もどうかと思います。
Re:あんまし関係がないと思う (スコア:2)
> そのためのコメントじゃないの？
コメントが書かれているからといってプログラムを
解析する手間がなくなるわけじゃない。
だってコメントが書いてあってもそれが正しいという
保証はない。
だから必ずコメントとコードが整合しているかチェックしなくちゃ
いけないけど、これがコードを直接、解析するより楽かどうかは
コメント(とコード)の品質による。
「優れたコメントは優れたコードと同じくらいプログラムにとって重要だ」
という言葉を聞いたことがある。(ストールマンがいってたような…)
しかし私は言おう。
「劣悪なコメントは凶悪なバグと同じくらいプログラムにとって有害だ」
と
Re:あんまし関係がないと思う (スコア:1)
＞「自称」やり手プログラマの中には、
＞コメントがなければ美しいコードだと勘違いしている人がいるようなので。
こっちの指摘はまあまあ理解できるけど、
＞そのためのコメントじゃないの？
それは必ずしも正しくないと思う。
コメントがあった方が良い局面というのはあるけれど、コメントがあればデバッグのための
ソースの解析が不要になるかというとそんなことはない。
たとえ自分が書いたプログラムやコメントでも、書いてから何年もたてば自分が書いた
内容の細部なんて忘れてしまいます。まして自分が当時気付かなかったミスについて
修整を頼まれたんだから、自分が当時正しいと思っていた仮定なんてあてになりません。
例えば，自分で書いた推理小説の密室トリックのアラを読者に指摘されて、推理小説の
辻褄があうようにトリックを書き直そうと思えば小説全体を読み直して書き換える必要が
ある。それには相応の時間がかかるのは避けられないと思います。
＞同様に「プログラマならemacsだろ！IDEなんか必要ない！」みたいな考え方の人もどうかと思います。
「IDEが使えない人」は困ると思うけど、IDEを使う必要は実はそんなにないと思います。
しょせんIDEなんて、単体のツールを集めただけの代物なんだから。
むしろ「IDEさえ使えればいい」、「単体のエディタなんて時代遅れだ」と思ってる人
の方がどうかと思います。そういう人はIDE付属の簡易エディタしか使ったことがなくて、
本物のエディタを理解していないんですね。酷い場合だと除き窓のような細いエディタ
領域の中から、横長で改行も入ってないようなコードを書いて平然としている人までいます。
機能単位で関数を分けると分散して読みにくくなると文句を言う人もいます。
あとJavaのように強力な型付けの言語で、それをIDEが解析して利用している場合なら
まだしも、Rubyのように動的な片付けの言語や、PHPのようにぐ支離滅裂な言語だと、
IDEの単体エディタに対する利点はかなり減るでしょうね。
Re:あんまし関係がないと思う (スコア:2)
＞＞ あと、修正前のコードをコメントアウトして残すことを強制されたコードも「Ugly」。
＞＞ バグ票番号を修正箇所にゴチャゴチャ残させるコードも「Ugly」。
＞ケースバイケースですが、これはちょっと断定しちゃうのは反対。
＞修正後のコードに問題が無いかの検証をするのに残すべき、という場合もあります。
十数年前だったら、それも一利あったかもしれない。
当時でも否定する意見は多かったけど。
今だとこれはバージョン管理システム＆バグトラッキングシステムで行うべきもの。
未だにそれを導入してない／導入したけど使ってないというのは、バカがすること。
「日本ではバカが非常に多い」という点については、残念ながらその通りというほかない。
Re:あんまし関係がないと思う (スコア:1, すばらしい洞察)
外れ。
外国だともっと進んでいるんだぜ、と思っているなら世の中を知らない。
また、外国も同様だという位知ってるというなら、わざわざ日本と前置きする意味が無い。
したがってその考えは「馬鹿と言うのは馬鹿」に当たっていないか？自問自答すべきだろう。
拡大解釈好きは、自分の論調に溺れがちだ。
Re:あんまし関係がないと思う (スコア:1)
＃ 消したあとのソースでテストしないのって？いや、やりますよ。
＃ そのときはさくっと流して初回テスト時と同じ結果かDiffだけど。
まー、今時はバージョン管理ソフト使ってるところも多いからここまでやらんでもいいとは思うんですが、やり方をがらっと変えてバグ作り込むよりはいいかなって感じです。やってるときは前のコードも見てたいしｗ
Re:あんまし関係がないと思う (スコア:2)
過去のバージョンとdiffとってみて。
たぶんエライコトなってるから。
ファイルのコピー残しとけば良いんじゃ...
Re:あんまし関係がないと思う (スコア:2, 興味深い)
> それって「ツールを使わなきゃ差分すらわからない」と同義でしょ。
> ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。
ツールを使いたくないのであればプログラマーとかIT業界にいないで転職した方が良いと思います。
IT業界で「ツールを知らない」「ツールを使えない」「ツールを使おうという意欲がない」というのは
ある意味決定的な問題です。自分にとっても周りにとっても。
対人恐怖症の人がカウンセラーやっているのと同じぐらい悲劇です。
IT業界人は前向きにメンドクサガリでないと:-)
> そうやって自力で管理することを放棄して、作成者にしか理解できないソースばかり生み出すのよね。
> あんたらが飽きて放り出したソースの尻拭いしてやってんだ。コメントぐらいふんだんに残せよ。
それはツールと関係ないのでは？
気持はお察ししますが。
Re:あんまし関係がないと思う (スコア:1, すばらしい洞察)
ある意味決定的な問題です。自分にとっても周りにとっても。
宗教家が原理論争やっているのと同じぐらい悲劇です。
#ネタですと言いきれない地獄
Re:あんまし関係がないと思う (スコア:1)
そういう場合はツールを使わなくても結局同じような悲劇が起こるので安心してください。
#宗教論争をするのは「神様を信じる人」であって、神様自身は論争しない
うじゃうじゃ
Re:あんまし関係がないと思う (スコア:1)
Re:あんまし関係がないと思う (スコア:2, おもしろおかしい)
えー・・・ネタだよね？ 一応突っ込んどくけど、
「共有フォルダに最新ソースがあります。修正前後の差分はコメントを見れば判ります。」
と言われて引き継いだら、src_20091117 と src_最新版 と src_最新 フォルダがあったらどうしますか？
ついでに、コメントは基本的に適当デタラメだったらどうしますか？
バージョン管理システムやバグ管理システムは、作成者が更新しますが、最終的に管理者が管理するものですよ。
管理者の人が管理しなかったら、作成者にしかわからない状態になりますが、それは自業自得ですね。
＃ ちなみに全部実話です（涙
Re:あんまし関係がないと思う (スコア:2, おもしろおかしい)
・diffを使うのはずるい
・それは実力ではない
・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。
・ツールを使うのはズルとしているのを同じ
ということでしょうか [okwave.jp]
Re:あんまし関係がないと思う (スコア:2, おもしろおかしい)
前の業者が逃げたあとの尻拭いをしたことがあります。つか、継続中だけど。
当然、そんな奴らの書いたコメントが当てになるはずがありませんので、邪魔な先入観を与えるだけのコメントなら、ないほうがマシという状況です。
正直
ってコメントには怒りを通り越して笑うしかない(笑)
詳細なコメントは、それ自体へのメンテナンスコストがかかるので、コメントが不要なくらいに理解しやすいコードを書くというほうに努力すべきだと思います。
# 昔 Linux-Users-ML でそんなスレッドがありましたよね。
Re:あんまし関係がないと思う (スコア:2, すばらしい洞察)
元コメじゃないけど、
＞コメントを信用しないってことは、関数名や変数名まで信用してないんでしょうか？
もちろんです。
>setなのに値を取得していて、getなのに値を設定しているじゃないかとか疑ってたら仕事になんない。
その通りです。
「下手なプログラマは存在自体が殺人的である」という事実を理解して頂けて幸いです。
他にもgetなのに副作用があったり、勝手に内部でカウントアップしたりくらいは日常茶飯事。
なんとかmanagerとかなんとかControllerって書いてあるけど、何をどのように管理するのか
サッパリわからないとかもよくありますね。
http://www.radiumsoftware.com/0603.html#060330 [radiumsoftware.com]
Re:あんまし関係がないと思う (スコア:2, すばらしい洞察)
うん、基本的に信用していない。
get～()って関数が値を設定していることはザラだし、isFoo()って関数が予想とは逆の値を返すこともよくある。
自分の書いたコード以外は信用できないし、自分の書いたコードはもっと信用できない。
Re:あんまし関係がないと思う (スコア:1)
＞>ツールなぞ使わずシンプルにソースだけで把握できることにメリットって感じないのかなぁ。
>目grepはツールに入りますか？
まったくです。
ソースだけで変更管理しようとすると、人間の目視では把握できなくなるんだってば。
こんな感じで
switch( a ){
case 1:
case 10:
case 2:
.....
case 100:
default:
}
/* 2001年10月31日修整
// 修整理由なんたらかんたら
switch( a ){
case 1:
case 3:
.....
case 10:
default:
}
*/
/* 2003年10月31日修整
// 修整理由なんたらかんたら
switch( a ){
case 1:
case 2:
.....
// 2003年1月10日修整
// 修整理由なんたらかんたら
case 18:
.....
//
case 10:
default:
}
*/
/* 2005年2月31日修整 // わざとです
switch( a ){
case 1:
case 10:
case 2:
.....
default:
}
*/
100行以上はある細切れの大量の修正前コードの中に、数行の最新コードが埋もれて
いるのを実際に見たことがあります。基本的に修正前コードは増え続けるのに対して、
機能追加しない限り最新コードはそんなに増えないですからね。時間が経てば経つ
ほど修整すればするほど、ソースのカオス化は進んでいきます。
そういえば、エディタによるコメントの色分けはツールに含まれないんですかね？
Re:あんまし関係がないと思う (スコア:1)
ところが、コメントでソース残す古い人は平気でそういうことやるから困る
ちょっと前までは
「バージョン管理なんて信用できない」
「古いソースがソース内にあったほうが効率がいい」
とかなんとか言って汚いソースで書いてたが、if文やcase文とかでコメントアウト部分と
ソース部分が入り乱れているのをみて「なんとかなる」とか言い放ちやがって、あの○○野郎！
…と一時期本気で喧嘩売ろうかとおもったが、うちの部署はすっかり
ツールが整備されたので今は不満がない
クオリティは一致する (スコア:4, すばらしい洞察)
コメントと実装がずれていた場合、設計書の内容も最新仕様と一致していない。
という事で、プロジェクトの管理自体がうまく回っていない。・・・ケースが多い。
個人的な経験では100%。
表現の範囲は把握しておく (スコア:4, すばらしい洞察)
なので、それらを総合的に合わせて一番適切な表現になる様にするのがベスト。
なぜそのコードが選ばれたのか？の意図はコードには表れない。
コードは自分が何かは表わすけど、それだけ。選択の意図するものが
最善なのか次善なのか、それともやっつけなのかわざとなのかはコードの記述範疇外だから。
Re:表現の範囲は把握しておく (スコア:1, 興味深い)
思われる手法ではなにが問題だったかは長くなっても書いておくべきだと思います。
ドキュメントは仕様を理解したらそんなに見ないですし。
コメントが必要ないのが綺麗なコードなんていうのは80年代で終わってますから。
Re:表現の範囲は把握しておく (スコア:1)
俺はコメントには「機能」を書きますね。どういう目的か。処理内容じゃなくって。
たとえば、0-9,a-z文字列（"0123ab"）をhex化（0x0123ab）するといった処理を書く場合、コードの塊の頭に
「// 16進文字列をHEXに変換する(端数が出たら残りは0x0埋め)」
とか。具体的に「// 文字列の長さを計測してループする」とか「// シフトして値をずらす」・・・とかって言うのはあんま書かないです。昔は書いてましたけど。
ところで、自分のソースの中に含まれるコメントの割合って行単位だと皆さんどのくらいあるんでしょうか？いわゆるコメント量のお話。昔自分の書いたコードを計測してきた結果、俺は「約30％」がコメント行でした。個人的にはこれくらいあれば（程度の差をあまり気にせず）分かってもらえると思います。
Re:表現の範囲は把握しておく (スコア:1)
「// 16進文字列をHEXに変換する(端数が出たら残りは0x0埋め)」
↓
「// ○○の項目に出力するために16進文字列をHEXに変換する(端数が出たら残りは0x0埋め)」
＃ 目的が抜けてました。
ある意味的を射ているかも (スコア:3, すばらしい洞察)
精度の低いコードを書く奴って、レビューで指摘してもウダウダ言い訳することが多いのは実感としてある。
仕様を理解した上での解釈の間違いであれば、指摘すればすぐに納得してもらえるし修正も早い。
また、「意味がわかんねーよ」とキレるのは、少なくとも「わかってない」という現実と対峙しているのでいいほう。
たちが悪いのは根本的に理解が不足しているのにそれを自覚していない奴。
概要レベルの仕様の解釈で屁理屈をコネ回す奴は、プロジェクトから外すのが正解。
コードレビューの次元でそもそも論とか持ち出す奴は敬遠したほうがいい。
ついでに過去の経験から言うと、変数名などの命名規約を独自解釈する奴は危険。
経験あり (スコア:2, 参考になる)
自信がないことを示すキーワードがある箇所は全部バグでした。
（なぜか,とりあえず,苦肉の策,うまく）
また、仕様書の曖昧なテキストがそのままコードコメントに貼り付けてあって、これもバグでした。
（日本語の論理演算「または・かつ」と否定演算「ではない」の組み合わせ。人によって解釈がまちまち）
ただ、コメントからのあら捜しは、かならずしもコードバグとは結びつかないので、絶対的なものではないですね。
納品前に妙なコメントは除去されることもあり、そうなるとその痕跡は消えますし。
Re:経験あり (スコア:2)
自分の書いたソース？ (スコア:2, おもしろおかしい)
ノーコメントです。
/.風にするのであれば (スコア:2)
と、モデレート機能をソースレビュー時に付ければ良いのでは？
あ、、、ソースも見れないや！コンパイルも げふんげふん。。。
呪いのコメント (スコア:2, 興味深い)
これは、私が昔体験した話です。
メールを読むのに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, おもしろおかしい)
InitNNN(0, 0, 1, 0); // よく分からんけど参考例をコピペ
h = WinInitialize(opt); // おまじない
とかやったことあります。
コメントもソースもさしたる問題はなかったけど (スコア:4, おもしろおかしい)
* (略)
* @author ピクミン
(以下略)
何故・・・。
// 悲しいけどこれ、実話なのよね・・・。
... from rakehelly programmer.
Re:コメントの例 (スコア:3, おもしろおかしい)
客先からメンテを依頼された某パッケージソフトの例
#直接言いなさいよ……
Re:コメントの例 (スコア:2, おもしろおかしい)
>// とりあえずちょっと多めに
>ちゃんと計算しろ。
>// よく分からんけど参考例をコピペ
>理解してから。
>// おまじない
>聞かないことが多い。
>とコメントしたことがある。
ちゃんとコメントアウトしようよ
コメントねえ (スコア:1, 参考になる)
コメントをどうこう言う暇があったらそんなもん全部消して実際のコードに注力しろよ。
あ、そういえばこんな話題が。
http://blogs.itmedia.co.jp/morisaki/2009/11/post-8f5d.html [itmedia.co.jp]
良い言い訳 (スコア:1)
出来る限りの最適化を加えてた結果としてどうしょうもなく読みにくくなって、それを緩和すべくくどい説明を添えることぐらいは許してください。
単純なところでは、
strcpy(dst + a + b + c, src); // 意図はstrcat(dst, src); ここまでの処理でstrlen(dst) == a + b + cなので
みたいな、(この例だと変数名が最悪なのは置いといて)分かってる値を使い回してステップ数を減らすところから、もっと凝りに凝った最適化まで。
ぱっと見て何が書いてあるのか分からない、と言う問題までは共通ですが、そういう場合に「じゃあどういう風に見て回ればその最適化で正しいと確かめられるか」のメモを残すよう心がけています。
最適化しなくてもいいような場所は、そんなことよりロジック・ソースを分かりやすくて無駄に長いコメントを付けなくていいようにすべきですが。
# argvの解釈を1ステップでも速くしようと血道を上げる最適化厨だった青春時代
Re:良い言い訳 (スコア:2, 参考になる)
うしろから羽交い絞めにして、
「やめろ、やめるんだ!!」
「はなせっ離してくれっっ、ここを最適化しないと…ここを最適化しないとっっ」
「ばかっ、そこで苦労してどうする。今じゃもう、gcc とかの最適化がそんな事は全部やってくれるんだっっ」
「な…なんだって… じゃぁ、俺の今までの苦労は…」
うん。もう同情に涙が止まりませんよ。gccの最適化の強靭さを見た瞬間の感動を君にも分けてあげたい。
.
ただ、そのためにコードを読みにくくするのは昔のコードであってもお勧めできません。
「アセンブラで組め」
「インライン アセンブリコードで組め」
で、コメントにCの読みやすいコードを書くんだ。
「いつか、良いコンパイラが出てきたら、このアセンブリコードは破棄するように」
というコメントをつけて。
fjの教祖様
Re:良い言い訳 (スコア:3, おもしろおかしい)
「コンパイラなんかアテにならない」
こういう小競り合いはしばしば見かけるが
毎回共通していることがある
どちらもコンパイラの出力を見ていない
Re:良い言い訳 (スコア:1, 興味深い)
コンパイラは「共通部分式の削除」だといった「小手先の最適化」はできますけど、
アルゴリズムレベルでの最適化は無理ですね。計算量のオーダーは変わらない。
計算量そのものが変わってくるような、例えば
を
に書き換えるような最適化はコンパイラには無理で、そういうの手で書くしかないし、それを突き進めていくと、どうしても可読性は悪くなるんですよね。
昔の自分が書いたコードで、「何を計算したいのか」「どういう式で算出しているのか」は一目瞭然なんだけど、
「なぜその式で答えが出るのか」がさっぱり分からないという羽目になったことがあります。
仕方ないので、ムダにもう一度悩んで悩んで、なんとかその通りに式変形できることを確認しました。
それ以来、私はそういう処理をした時は、コメントに式変形過程を残したりしてますけど、そもそもテキストベースで「数式を書く」こと自体が難しいという問題があるんですよね。
TeXスタイルは厳密な数式表現はできるけど可読性悪いし。
結局、アスキーアート駆使して書いてます。
Re:良い言い訳 (スコア:2, 参考になる)
そんな事はありません。Tail-Recursionコードをジャンプに変更する等は今でもやってくれて、スタック消費量などを大幅に削減してくれます。単に「あまりにも優先度の低いレアパターン」だから標準で組み込まれていないだけです。
ようするに「無理」なんじゃなくて「無駄」なんですよ。
一方で、sprintf( dst, "%s", src ) とかは gcc-4 でコードを吐けばわかりますが、
strcpy( dst, src )
に勝手に書き換えてくれます。
fjの教祖様
Re:良い言い訳 (スコア:1, すばらしい洞察)
>strcpy(dst + a + b + c, src); // 意図はstrcat(dst, src); ここまでの処理でstrlen(dst) == a + b + cなので
この程度の最適化はコンパイラに任せるべきだと思うし、コメントよりも
const int offset_ここまでの処理でずれたと言うことがわかる名前 = a + b + c;
strcpy(dst + offset_ここまでの処理でずれたと言うことがわかる名前, src);
とかするとソースコードが意図を見せてくれると思うのだけどそういうのじゃだめなの？
Re:良い言い訳 (スコア:1)
なるほど。・・・ただその場合、「この変数はソースを見やすくするためだけのものです」とのコメントがないと混乱しそうな気がするんですが、そういう気がするのがもはや時代遅れなのかなorz
Re:良い言い訳 (スコア:1, 参考になる)
オフセットな変数を一時しのぎに作るから混乱するんでしょう。最初から
strcpy(dst+dst_offset, src_a); dst_offset += length_a;
strcpy(dst+dst_offset, src_b); dst_offset += length_b;
strcpy(dst+dst_offset, src_c); dst_offset += length_c;
って感じでやってれば問題ないかと。printf系は格納した文字数を返すので、この方法だと、
dst_offset+=sprintf(dst+dst_offset, "%d", value);
って出来て便利。最も、バッファオーバーフロー対策でsnprintfを使ったりすると、snprintfは「書き込んだ文字数」ではなく「必要な長さ」を返すので、この技が使えず、
snprintf(dst+dst_offset, dst_rest, "%d", value); len = strlen(dst+dst_offset); dst_offset += len; dst_rest -= len;
見たいな、効率面でダメダメなコードを書いたりすることもあったり。
Re:コメント抽出 (スコア:2, すばらしい洞察)
Re:コメント抽出 (スコア:3, おもしろおかしい)
そうやって、コードもコメントも完璧なソースがコンパイルもされずに誰かのハードディスクの片隅から納品後に見つかるんですねわかります
ソース内だけじゃなく外部管理もちゃんとしてくださいよ！！！
Re:コメント抽出 (スコア:1)
が、その昔ありました。
それで、生成された意味不明のドキュメントを納品された私は
思わず、ぶっ飛びそうになったとさ。
Re:コメント抽出 (スコア:2)
doxygenはそこそこ使えるぞ。
てか、普通に使ってます。
Re:後でなんとかする (スコア:1, 興味深い)
そうなんだけどね、
有名な開発者がそれをやってくれちゃうと、もう俺のような凡人が触るなんて怖くてできないよ。
書き換えて「なんとかしてやったぜ！」なんて言っちゃうと、
山のように「お前のコードの正当性を説明しろ」「これこれこういう場合は考慮したのか」とか
文句がやってくるんだぜ。しかも英語か英語みたいなので。
それに対して英語で反論なんてしてられねーよ。
Re:コメントにし難い内容 (スコア:1)
1回だけ, AVL木のコーディングをした時にコードの横に対応する木の変形をAAで書いたことがあります.
本当はglobal [gnu.org]みたいな感じで, コード中に対応する設計ドキュメントへのアンカーを埋め込めれば便利なんでしょうけど.
Re:コメントでソースコードが書ける (スコア:2)