コメント研究すれ。

1 ：2008/03/20 〜 最終レス ：2013/06/21

Ｃ言語でコメントを書く時とても迷うよな？
・見易さ
・書き易さ
・分かり易さ
・一貫性（統一性）
・とどけこの思い

とか、何でもいいからいい感じのコメントの書き方を考えませう。

2 ：

/* 早く帰りたい */

3 ：

>>2
それは多分こっち
マ板：印象に残ったコメントを晒せ　0x04
http://pc11.2ch.net/test/read.cgi/prog/1190866177/
>>1
ていうか迷わない

4 ：

//　　 _,,....,,_　 ＿人人人人人人人人人人人人人人人＿
//-''":::::::::::::｀''＞　　　ゆっくりしていってね！！！　　　＜
//ヽ:::::::::::::::::::::￣^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^￣
//　|::::::;ノ´￣＼:::::::::::＼_,. -‐ｧ　　　　　＿_　　 _____　　 ＿_____
//　|::::ﾉ　　　ヽ､ヽr-r'"´　　（.__　　　　,´　_,, '-´￣￣｀-ゝ 、_ イ、
//_,.!イ_　　_,.ﾍｰｧ'二ﾊ二ヽ､へ,_7　　　'r ´　　　　　　　　　　ヽ、ﾝ、
//::::::rｰ''7ｺ-‐'"´　 　 ;　 ',　｀ヽ/｀7　,'＝=─-　　　 　 -─=＝',　i
//r-'ｧ'"´/　 /!　ﾊ 　ハ　 !　　iヾ_ﾉ　i　ｲ　iゝ、ｲ人レ／_ルヽｲ i　|
//!イ´ ,' |　/__,.!/　V　､!__ﾊ　 ,'　,ゝ　ﾚﾘｲi (ﾋ_] 　　 　ﾋ_ﾝ ).| .|、i .||
//`! 　!/ﾚi'　(ﾋ_] 　　 　ﾋ_ﾝ ﾚ'i　ﾉ　　　!Y!""　 ,＿__, 　 "" 「 !ﾉ i　|
//,'　 ﾉ 　 !'"　 　 ,＿__,　 "' i .ﾚ'　　　　L.',.　 　ヽ _ﾝ　　　　L」 ﾉ| .|
//　（　　,ﾊ　　　　ヽ _ﾝ　 　人! 　　　　 | ||ヽ、　　　　　　 ,ｲ| ||ｲ| /
//,.ﾍ,）､　　）＞,､ _____,　,.イ　 ハ　　　　レ ル｀ ー--─ ´ルﾚ　ﾚ´

5 ：

コメントなんて不要

6 ：

javadocで書いてるトコ多いんじゃないの？

7 ：

バグ直してもついでにコメントを直す奴はいないだろｗｗｗ
コメントはほとんどウソです
書いちゃいけません

8 ：

そういえば本屋でネーミングについての本が売ってた。
ネーミングの掟と極意
http://www.amazon.co.jp/o/ASIN/4798114332/503-8563893-6507141?SubscriptionId=1CVA98NEF1G753PFESR2
わざわざ本を買うほどのことでもないとは思うけど、俺みたいに年中違う会社に行っている下請け屋からすると
変数名、コメントのつけ方に規定がない会社で、コメントや変数名にレビュー指摘を受けると殺意を覚えるな。
例えば
�@ /* bErrorFlgがtrueならば */
�A /* 例外フラグが立っているならば */
�B /* 例外ならばaをbに変更する処理 */
�C /* bErrorFlgがtrueならば中に入る */
if (true == bErrorFlg) {a = b;}
たったこれだけの処理でも会社ごとに�@�A�B�C＋αパターンの書き方がある。
自分的には�Bが好きで処理概要をif文の前にずらずらと書いてしまうほうが好き。

9 ：

あと、漏れはJavaの業務経験はそれほどないのだが、
get, setの名前のつけ方って何がいいのかわかんない。
例えば同期データの送信を行う処理があって、送信結果が返ってくるとしたら、メソッド名はどうつける？
今のプロジェクトでは以下だが、
/* データ送信結果を取得する */
getSendResult()
getResult()
漏れ的には送信するのがメインの処理で、戻り値はおまけなのだからメソッド名は
/* XXXを送信する処理 */
sendXXXMessage()
sendXXXData()
とかにしたいわけなのさ。誰か教えてエロい人。

10 ：

前者は結果をとるだけで、後者は送信も実行するんだからメソッドの内容がちがうんじゃないの？
前者は非同期かなんかで送信は別に呼び出して、その結果を知るために使うものなんじゃ。

11 ：

わざわざ true と比較なんてしなくても・・・。
そもそも、エラーなら a を b に変えるということくらいは一目で分かるから
その例だとあまりコメントを書く必要性を感じないな。
書くにしても、a を b に変えることに何らかの意味があるなら、
その意味を書いた方がいい。

12 ：

学生時代はmanの文書を手本にしろといわれたな
関数中の変数名やら処理の意味が見て分からないような関数は
とっととリファクタリングしちまえや、と。

13 ：

単なる和訳が最低だよね。
int i; /* i を初期化しています */
i=0; /* i に 0 を入れています */
単に同じプログラムをプログラミング言語と日本語で二重に書いているだけ

14 ：

なんでひまわり導入しないんだろうな

15 ：

>>13
自分の為の覚え書きなんだろうね
そういうの引き継いで、かつ内容が間違ってたりするともうぬるぽ

16 ：

>>10
私もそう思います。
しかし、今の会社ではどうやら「戻り値」に着目してメソッド名を決めているようだ。
（規約なんかは勿論無い！）
>>11
うっかりtrueと比較する癖が抜けてないなぁ・・・
ちなみにtrueと比較しているのは規約です。
製造業のCプログラム辺りだと
以下の記載が許されない会社の方が多いと思う。
if(bErrorFlg) or if(!bErrorFlg)
boolがintになっても対応可能だからとかいう理由だったような。
if (ERR_STATE_1 == bErrorFlg)
>>13
そういう規約がある会社もあるぞ。
必ず一行につき一行コメントを書けって言う会社。
そういう場合には仕方なく書いた覚えがある。

17 ：

>>8
いまだに、if() 文中で定数を左に書いてる奴がいるんだ...
そっちにびっくりだよ。
>>13
> int i; /* i を初期化しています */
初期化してないし。(w

18 ：

>>17
>そっちにびっくりだよ。
どうして？？

19 ：

と思ったけど分かった
昔の人に多そうなテクだよね

20 ：

>>16
だったらtrueと比較するのではなくfalse (0)と比較するほうがいい。

21 ：

>>18
以下の代入ができてしまうコンパイラや設定が可能らしい。(普通はエラーかワーニングがでるけどね。)
if (bErrorFlg = true) {}
左に書いてあると、確実にエラーになる。
if (true = bErrorFlg) {}
製造業だと今でも普通に使われる規約の一つだぞ。

22 ：

>>16
> boolがintになっても対応可能だからとかいう理由だったような。
理由になってないと思うが・・・。
多分、そういう規約作ってる奴もよく分かってないんだと思うぜ。
>>21
そういうこと分かった上で言ってるんだと思うが。

23 ：

true と比較しても危険性が増えるだけであまり意味が無い。
どうしてもというなら != false になるが、
これも二重否定で可読性に難があると思う。

24 ：

bool から int に変えて、新しくフラグを追加した時にも、
true との比較ならそのままのコードで通るってことじゃないかな。
そのままのコードで放置することがいいことかどうかは知らんが、
フェイルセーフということならありかもしれない。

25 ：

むかし「偽以外は全て真の可能性があると心得よ」
とか教わった

26 ：

装飾が多いコメントは見づらい
////////////
//むほむほ//
////////////
/***********
　　うはうは
************/

27 ：

>>24
if (hoge() == true) ・・・
みたいなソースなのに、hoge()が、bool値を返してなかったら、カオス過ぎるだろ。

28 ：

変更はするが、変更洩れがあっても動く、ってことだな。

29 ：

bool値のリテラルと比較してるソースってすごい素人くさいよな。
世間で評価されている書籍とか、プロダクツのソースとかで、それをやってるのはすごい少数派。

30 ：

スレチの話題で盛り上がってる券

31 ：

「コメントに関する無意味な話」になってないだけマ板よりマシ
そういう向きにはマ板のスレが適切
間はない

32 ：

/* test code */
条件コンパイル使えって話もｗ

33 ：

突っ込みどころを探すスレはここですか?

34 ：

関数の説明書きって皆どうやって書いてる？

35 ：

規約があればそれに従う。
そうでなければ関数と引数と戻り値の説明を書く。

36 ：

それをどう書くか聞いたつもりなんだけど・・・。

37 ：

cだとdoxygenizeのjavadocスタイル
javaだとry

38 ：

>>36
精子を出す関数
チソチソをマムコに突っ込む
戻り値-精子

39 ：

精子を出す関数がマムコに突っ込むのか？
戻り値が精子なら、セクースの実装は分離すべきだろ
副作用についての記述が分離できなくなるし、絡み合い過ぎて再入可能性が損なわれそうだ
再入可能じゃない精子を出す関数なんて大問題だろ

40 ：

年賀状の配達は無事すんだかどうかわかりますでしょうか。

41 ：

自分は、DoxygenでJavadoc風の書式を使ってます。
Qt風の書式は余り好きじゃないんで。

42 ：

MFCのソースとか見ると、ほとんどコメントなんてついてないよな。
最先端のところでは、コメントを極力書かないのが、主流なの？

43 ：

Q. 自動保守#K9K?_D[L　とは一体何なのか？
A. 外部サイトへの突撃大好きな真性厨房
韓国突撃でお馴染みの自動保守
最近は自動焼人 ★として２ちゃんねるのボランティアにも精を出す日々
だがそんな彼にも、人間らしい部分はあったのだ…
名言集
『アパッチ砲はワシが作った』
『お前が規制系キャップ取れるか審査してやるよ』
『いつもサボってばかりのキャップがウゼえ』
『俺、100人規模の集団サイバーテロの主犯だったこともあるんだぜ』
『俺の経歴カックイイだろ？』
最近のニュース
　8月15日の韓国突撃の際に歴史的大敗を喫する。ラジオでの敗戦宣言のときに声が震えていた
　本人は体調不良と言っているが…

----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください

44 ：

コメントを書くべきか書かざるべきか
http://www.infoq.com/jp/news/2010/03/To-Comment-or-Not-to-Comment

45 ：

>>44
> Kelly Leahy氏は、一目瞭然のわずかなコメントが散りばめられているようなコードが好みだ。
この訳はおかしいな。
「ごくわずかなコメントがところどころにある自己説明的なコード」が正解かと。

46 ：

１行毎に 「/* */」使ってスペースで「*/」の位置合わせてるコメントとか個人的にかなりウザイんだが…
メンテする時も行端合わせにゃならん気がしてスペース連打、でもメンドくなって 「//」

47 ：

つ[プロポーショナルフォント]

48 ：

いや、フォントの問題を言ってるんじゃないと思うが・・

49 ：

プロポーショナルフォントでカラムを揃える気になるか? つまりはそう言うことだ。

50 ：

うちには来ないでください

51 ：

１行コメで /* */ 使う人って何考えてるの？

52 ：

C89なんだろ

53 ：

/*

54 ：

うひょおおおおおおお ！！！！
明日から毎日休みだぜぇ〜！！
*/

55 ：

C89でやってるとこまだあるの？

56 ：

ネストできないコメントなんてRばいいと思うの。

57 ：

ブロックコメントで/**/使って箱型にするのやめてくれよ、マジで

58 ：

ズレを直すためにスペースキーを連打することに恍惚を覚える

59 ：

ブロコメはソース行頭くらいでしか使う気にならない

60 ：

必要な処理はすべてプログラム自体にかかれている。
だから、プログラムコードを読んでも、すぐに分からないことをコメントにしてほしい。
例えば、関数の要約とか、そのように処理をしないといけない理由や意図などといったことだ。
それがプログラムの読者が疑問を持った箇所に書かれているならば、良いコメントだ。

61 ：

まずコメントにして、それをコードに直していく。
だから、コードを全部書き終えるとコメントがなくなる。
仕事は別。

62 ：

会話もできないやつらにコメントなんか出来るわけない

63 ：

カオスラウンジもpixivもしんで。

64 ：

/********************************************************/
/*　こういう箱型ブロックコメント、いい加減やめませんか？　　　　　*/
/*　タイプ量増えるしメンテめんどいの判りますよね？　　　　 　　　　*/
/*　後でメンテする人の身にもなってください。　　　　　　　　　　　　　*/
/********************************************************/

65 ：

/*
おれは普通にこうしてるでゲソ
日本語つーか最後に\x5cがきてもおーけーゲソ
\x5cでトラブルのは怖いでゲソ
いまだにSJISで書いてるのは突っ込まないで欲しいでゲソ
*/

66 ：

/*
120228 ageてしまったでゲソ
コメントはなるべく日付入りで書いとくべきでゲソ
何を思って書いたのか3日経つと忘れてしまうでゲソ
>>37 doxygen形式なんかはお勧めできないでゲソ
別ファイルじゃどうせ見ないしはっきりいって面倒なだけでゲソ
時間を無駄にしたなでゲソ
*/

67 ：

Doxygen 形式を勧めない理由が判らん。
別ファイルじゃ見ないってのは判るが、ソース中に埋めているんだからいつでも見られるだろ。

68 ：

どうせ見ないゴミのためにコメントが汚染されるのが嫌なんだよ

69 ：

何その教条主義。

70 ：

#if 0
// 自分の中のベスト
#elif 0
// だめだこりゃ
#elif 0
// まあまあ
#else
// これが基本形
#endif
javaにはできない芸当

71 ：

とりあえずバージョンコントロールソフトちゃんと使え。
それで残るようなやつは実行時 if で書いとけばいいよ。
そうすればちゃんとコンパイルエラーも出るしな。

72 ：

↑ちょっといみわからない
くやしく！

73 ：

>>72
void func()
{
if (0) {
// ここに書いておくと実行されない(最適化で消えるかも)がコンパイルは行なわれる。
SomeTestFunc();
} else if (0) {
// こういう風に幾つも書けるのも、#if と変わらない。
SomeBetaFunc();
} else {
// ここに書いてあるコードが最終版
SomeReleasedFunc();
}
}

74 ：

コメントもコンパイルされるようにならないかな
コメントメンテされずに実装と不一致してるプロジェクトとかもうこりごり
信じることできないコメントとかどうなん

75 ：

>>74
コンパイルしたいだけなら>73でいいが、要は不適切なコメントを排除したいのだろ。
引き数の説明の不一致なんかはある程度はDoxygenで管理していれば警告してはくれるけど、
その先は人力でやるしかないだろ。つーか、コードレビューもしないのけ?

76 ：

if (status) { // 接続完了？

}
if文のコメントに「？」付けるな、断定的なコメントにしろ
｛　｝内の実行条件がどっちなのか一瞬不安になるだろ

77 ：

俺が今までに見た最強のコメント。
a=1; //aに1を代入

78 ：

>>77
そういうのはコメント書け書けとうるさい奴に対する嫌がらせでわざとやってるんだろう
もしそうじゃなかったら、そいつは即刻クビ/留年にすべきだ

79 ：

>>76
if文で判定していることそのものを指すときには疑問文にすることはしばしば。例えば、
--
if (fp == NULL) { // ファイルは開けなかった?
--
こんな感じ。
>76の例は変数名が不適切だからそれを補う意味ではありではないかな。

80 ：

>>76
怒るとこ違うんじゃないの？
俺だったらif (status)とかいう意味不明な変数名じゃなくてif (connected)とかにしろと言うな。

81 ：

>>76
どう考えても{}内は接続完了のときの処理だろ。
{}内が接続完了出来なかったときの処理なら怒る。

82 ：

＞{}内が接続完了出来なかったときの処理なら怒る
実際あるから困るw
何かエラーが発生したら0以外のエラーコード返すようなの

83 ：

/**//**************
コメント内容
*******************/
関数宣言
最近はこんな感じの書き方してる。
最後のスラッシュ削れば後ろに書いた関数がまとめてコメントアウト出来る

84 ：

これは、イライラするな

85 ：

＞/**//**************
半端な所にある // も含むの？

86 ：

キモすぎ

87 ：

/**//*************
******************/←これを外すと
func(){ }
　　↓ここまでコメントアウトして止まる
/**//*************

88 ：

/******************
コメント内容
*******************
関数1
/******************
コメント内容
*******************/ ← 結局ここで止まるから//無くても同じじゃね？
関数2

89 ：

吊ってくるノシ

90 ：

コメントが真であるためには、コメントに責任を持たせればよい。
http://nojiriko.asia/prolog/prolog_55.html
の中に現れる、資料/2という述語定義とそれを呼び出す副目標は
意味的にコメントである。
こうして置けば、コメントが書き換わっただけだと、プログラムの実行が
偽になってしまう。

91 ：

//*
最初の/の有無でほげほげ
//*/

92 ：

適度に遊びを入れて______s----------z______みたいな区切りって使えないかな
やっぱ怒られる？

93 ：

コメントには処理の目的を書いて欲しい
// 高さを取得する
じゃなくて
// カーソルの有効判定をするために高さを取得する
ってな感じ

94 ：

>>93
それ、「カーソルの有効判定をする」メソッドにして、「高さを取得する」のコメント無しの方がいいよ。

95 ：

// おまじない
// メイン関数
// 変数定義
// for ループ
// 代入
// プリント関数
// ゼロをリターン

96 ：

>>90
こっちの方がいいんじゃないか
http://nojiriko.asia/prolog/bsort_2.html

97 ：

>>79
if文が条件判断なのは明らかだからコメントを疑問形にする意味がないと思う

98 ：

コードで書いていることを
コメントにするな。

99 ：

>>98
解説してはいけないの？

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

マルチプラットフォーム プログラミング言語 haXe (110)
LLにおける関数型プログラミング (103)
【COBOLから】バッチ処理【Javaまで】 (152)
【GNU】スクリプト言語 Guile【scheme】 (105)
スレ立てるまでもない質問はここで 127匹目 (191)
十進BASIC (127)
--log9.info------------------
大分第二勢力HOYO AC ELAN大分part2 (623)
ジュビロ磐田　Part626 (948)
■言いたい放題FC東京 1959■ (536)
■ サッカー関連番組が始まったらageるスレ45 ■ (790)
奥大介容疑者 (247)
スパイク、トレシュー、サルシューを語ろう６ (797)
〔球技専用〕全国のスタジアム査定�A〔陸上競技場〕 (638)
有望選手の海外流出が相次ぎ、Ｊリーグが空洞化！？ (285)
【J1土曜】固定開催について語る【J2日曜】 (206)
なんで練馬区にJリーグ無いの？ (122)
【雷鳥は】松本山雅FC【J頁を目指す】 第260峰 (1001)
■□■□■ ヴィッセル神戸 Part 628 ■□■□■ (944)
◆◇◆　横浜F・マリノス　part1039　◆◇◆ (917)
解説者・実況アナについてPart11 (652)
やばいぞ!!横浜FC　Part254 (512)
レディアくん　その9 (446)
--log55.com------------------
【今宵もうた動画】エレカシの噂【いつもの如し】
【アンサング祭】林遣都の噂335【37歳】
高橋くん 112人目
King Gnuの噂vol.227
男女交際（記事専用）　 映画興業収入禁止52
King Gnuの噂vol.228
【追加されない】林遣都の噂336【遣都のスケ】
DPの噂・雑談スレPART285