アカウント名:
パスワード:
// コメントの始まり /* ...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
コメント (スコア:2, 参考になる)
プログラムなんてカッコイイ物は書けませんが、手間を省くためちょっとしたマクロを書いた時など、
後で見るとわからなくなることがありました。
やっぱり、コメントは重要です。
Re:コメント (スコア:2, 参考になる)
面倒と思って書くコメントほどいいかげんになりがち。
ヘタしたらコピペの書き換えミスとか古いコメントの改訂忘れで
嘘になっているようなところもよくある。
コメントを過剰に義務化するからこうなる。
だから俺は、複雑な部分,試行錯誤した部分に限定した上で
詳しく書けと教えてる。
--
Ath'r'onならfloatあたりに自信が持てます
Re:コメント (スコア:1)
それはコメントではなくて、虚偽とか間違いってことでは?
>コメントを過剰に義務化するからこうなる。
最初の「面倒でも」は義務化されているかは論旨の外だと思うよ。
嘘を書いてしまう可能性があるから、コメントを書かないという手もありかもしれないけどね。
>だから俺は、複雑な部分,試行錯誤した部分に限定した上で
>詳しく書けと教えてる。
そこで、難しくなってしまったこと、試行錯誤の結果での「これはこうなるから」という理屈ではない
事を書くのも、危険。
わたしがやっていた時には、数人で読み合わせをして、コメントの虚偽誤記を含めて、等しく間違いは「バグ」として処理させていた。
Re:コメント (スコア:2, 興味深い)
ソースコードの全行にわたってコメントを書いてあるのは逆効果ですよ。
見づらくてしかたないのです。
それでもまだ、内容が論理的なところまで叙述できてればまだ少しはいいのですが…
// 整数型変数i に0を代入する
int i = 0;
なんてコメント書かれてもね…。
誰に説明しているつもりなんだろうと。
当人いわく、新人君にもコメントの書き方の見本になるようなコメントを書いたとのこと。
見事に見本になってます。反面教師の。
# いいや。IDで。
Re:コメント (スコア:3, おもしろおかしい)
コードの質は推して知るべし。
……ええ、そっこーその仕事から逃げ出しましたとも。
# 書いたのは別の会社のまったく知らない人でした。
Re:コメント (スコア:2, 参考になる)
>見づらくてしかたないのです。
同意。
個人的には
1. 関数の頭には何行でも関数に関する説明を書いていい
2. 関数内部はいずれかに限り手短にコメントを入れる
- if文等の分岐条件に関する解説
- ミスリーディングしやすい部分の補足
- 仕様上回避できないコンパイル時警告に対する言い訳
というルールでコーディングしてます。このルールで不十分なコメントしか書けない場合はたいてい関数の作り方が腐ってます。
(ちなみ、いわゆる「しみったれた高速化」は要求されないというのが前提です)
Re:コメント (スコア:1)
*Don't just echo the code with comments – make every comment count.
あと、こういうのも
*Don't comment bad code – rewrite it.
Re:コメント (スコア:1)
そうなると、個々の項目に対してコメントが必須になります。
よくCOBOLに近い、といわれるので、それを思い浮かべれば良いかもしれません。
はっきり言って、プログラムは、コメント地獄になります。
その分、誰でも理解できる言語なんですけどね。
まつもとゆきひろさんみたいな人が見たら、発狂しそうな言語仕様ですが。