回答編集履歴
1
回答の追記
answer
CHANGED
|
@@ -1,7 +1,5 @@
|
|
|
1
1
|
(念のため確認ですが、これって仕事で書くソースで、ソース中に「/**/」とか「//」とか「#」とかで書くコメントの話ですよね。)
|
|
2
2
|
|
|
3
|
-
ほとんど皆さんの意見に同意ですが、少し気になる点について。
|
|
4
|
-
|
|
5
3
|
私が数多くの現場を渡り歩いてきた経験から言うと、コメントに愚痴・独り言・ぼやき・いいわけ・他メンバーの批判・ポエム等を書くのはご法度でした。
|
|
6
4
|
そんなソースをコミットしたら、レビュー前に注意されるか注意します。
|
|
7
5
|
他のプログラマーのコーディングに問題があれば、コメント経由で注意するのではなく、別の手段で伝えます。
|
|
@@ -9,4 +7,16 @@
|
|
|
9
7
|
- ベンチャーか、普通の会社か
|
|
10
8
|
- 自社で完結しているソースか、最終的に他社に納品するソースか
|
|
11
9
|
|
|
12
|
-
によっても違うかもしれません。私は後者の現場が多かったです。
|
|
10
|
+
によっても違うかもしれません。私は後者の現場が多かったです。
|
|
11
|
+
|
|
12
|
+
(追記)
|
|
13
|
+
本題について。
|
|
14
|
+
昔から「コードを読めばわかるコメント」は不要と言われるのは
|
|
15
|
+
```
|
|
16
|
+
// 変数aに3を代入
|
|
17
|
+
a = 3;
|
|
18
|
+
```
|
|
19
|
+
上記のことで、その関数が何をやっているか(関数ヘッダーコメント)、関数の中で処理の固まりに対して何をやっているかは、当然のように書きます(そこに個人の感情を入れないのは前述の通り)。
|
|
20
|
+
そのソースをレビューする人やメンテナンスする人の、言語や仕様に対する理解のレベルは個人差があるからです。
|
|
21
|
+
スキルが高い人、あるいは何カ月か後の自分自身だって、日本語で一言二言書いてあったほうが理解が早いでしょう。
|
|
22
|
+
「読めばわかるのだから書かない」を突き詰めると、コメントが全く無いソースが理想的ということになりますが、仕事の成果物としてはナンセンスですね。
|