コメントを書く人、書かない人

コメントを書くのは常識だと思っていたのは
この仕事を始めて最初の2,3年だけだった。

今まで出会った何人かの凄いプログラマ達は
みんなコメントが少なかった。
（ただし、ソースを読むだけでは読取れない
情報についてはしっかりとコメントが書いてある。）

というわけで、私はほとんどコメントを書きません。
さて、あなたは？

>>1
意味のないコメントはいらない。自分では面白いと思っている
コメントもいらない。
的確なコメントさえあればいい。

でしょ？
ソース読めないやつほど「コメントが少ない」
なんて言うんだ。
お前だよ、T森

汚いソース書く奴ほどコメント要らないってんだよな

コメントはあった方がいい。
変数の意味とかビットに割り当てたフラグがなんだとか。
修正するとき大変だよ。いちいち調べなきゃならない。

>>5
ビットフラグを使うなら、列挙子やマクロを
使って、それらの名前に意味を持たせたらいいのだ。

整数リテラルで直接ビットをいじるようなソースは
問題外。

自分のソース半年寝かせてから見てみ。
どういう意図で書いたロジックか思い出すのに苦労すること請け合い。
無限に時間を浪費できると勘違いしてる学生プログラマなら放置だが、
給料もらってプログラム書くなら悔い改めろ。

そうかな？
もうプログラマを10年やってて、古い自分のソースを
みることはたまにあるけど、だいたいわかるぞ。

どうしても不思議な部分というのは、やっぱりコメントを
書いてたりするわけだが。

自明なことにはコメントは書く必要はない。
変数の命名法にも一貫性があれば、コメントは必要ない。
でも、重要な処理の流れや、後で調べるのが大変な個所とかは入れるべきだ。

あまりにも、コメントを入れすぎると時間がかかるし、プログラムのポイントが
見えなくなる。

関数と関数の間に書くセパレータ
何かカッコ良いのない。
####################################
とか
////////////////////////////////////
とか
/**********************************/
とか
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
とか
//separator_separator_separator_separator_separator_
など。

>>6=1
＞ビットフラグを使うなら、列挙子やマクロを
＞使って、それらの名前に意味を持たせたらいいのだ。
べつにそのうえ、コメントがあったっていーじゃん。

＞整数リテラルで直接ビットをいじるようなソースは
＞問題外。
でも仕事やってるとでてきますよ。元アセンブラ->Ｃに書き直したようなソフトだから。
似たような変数をグローバルにいっぱい持ってるし。

さらにひどいのは固定アドレスに変数を宣言していて、それらをクリアする関数とかがあるの。
だからうっかり変数を追加するといつの間にかクリアされてたり。

/*3456789012345678901234567890123456789012345678901234567890123456789012345678*/

コメントを書かなければわからないようなコードは
コメントを書いてもわかりません。

>>10好きなのをどうぞ！
/*ｺﾞﾙｧｺﾞﾙｧｺﾞﾙｧｺﾞﾙｧｺﾞﾙｧｺﾞﾙｧｺﾞﾙｧｺﾞﾙｧｺﾞﾙｧｺﾞﾙｧ*/
/*ﾏﾝｾｰﾏﾝｾｰﾏﾝｾｰﾏﾝｾｰﾏﾝｾｰﾏﾝｾｰﾏﾝｾｰﾏﾝｾｰﾏﾝｾｰﾏﾝｾｰ*/
/*氏ね氏ね氏ね氏ね氏ね氏ね氏ね氏ね氏ね氏ね氏ね*/
/*ttp://www.2ch.net/ttp://www.2ch.net/*/

>>14
半角カナは敬遠される風潮があるので
/* ageageageageageageageageageageageageageageageage */
/* sagesagesagesagesagesagesagesagesagesagesagesage */

>>11
　っていうより、この場合は壱から書きなおしたほうが
幸せになれるような気がしますが…

　ちなみに、私はトリッキーな部分以外は特にコメントを
書いていませんが、コメントがいらないようなプログラムを
書くようにしています。

自分の書いたソースコードは誰がメンテするか分りません。
それは自分よりもずっとスキルの低い人かもしれません。

スキルの高い人がコメントを読み飛ばすのは簡単だろうから、
コメントはできるだけ分りやすく、多少は冗長性を持たせて書こうとしてます。

あと、コードとコメントで内容に矛盾があると、
それはそれで大変なので、コメントと言えども気を抜かないようにしています。


さらに言うと、私はコーディングの時に一番最初にするのは「コメントを書く」です。
まあ、ＰＡＤとかを真面目に書いていない証拠かもしれませんが。

私の書くソースは達人レベルではないので
コメントは書きます。つか、コメント好きかも。

如何にみやすく、かつ、有用なコメントが書けるか、
に萌えています。書き過ぎても邪魔だし、メンテ者が
継続して書くのに困らないよう配慮も必要だし。
コメント負けするソース書きたくないし。

ただ、確かに慣れてきた部分はソースがコメントみたい
に見やすくなって不要になってくるんだよなぁ。
先は長いけど。

無茶な仕様を突きつけられたときとか、
どー考えても仕様が変なのに、押し通された時、
自分では理解不能な定数や計算式を入れるときは
文句と共にその旨を書き込んでる。

コメントに愚痴が・・・
http://mentai.2ch.net/test/read.cgi?bbs=prog&key=958529463

>>14,>>15
2チャンネラーってばれちゃうネ。
/* （ ・∀・）ﾌﾟﾛｸﾞﾗﾏｶｺｲｲ!!→(゜д゜)ｳﾏｰ→（ ・∀・）ﾌﾟﾛｸﾞﾗﾏｶｺｲｲ!!→(゜д゜)ｳﾏｰ→ */

>>10
/*----------------------------------------------------------------------------*
関数名 ：void vUsage();

機能概要：使用法を表示する。
引数 ：なし
戻り値 ：なし
修正履歴：2000/06/18 ◯◯夫 初版
*----------------------------------------------------------------------------*/

漏れはこんな感じ。
# スペースは好みで入れてくんろ。

コメント書いても読まずに、「分かんねえ」って威張る奴がいた。

pop eax ; スタックからeaxをPOPする
inc eax ; eaxに１を足す
みたいなコメント書くやつ、ほんとにいるのには参るな。

>>1
今までに出会った凄いプログラマって、どういうふうな意味で
凄かったのかおせーて。
開発時間が他の連中の三分の一以下ですごい稼ぎがしらだったの
がいるけど、ソースのコメントは少なかったね。

>>8
わかるって事は違和感が無いって事だよな。
10年前と同じレベルのソース書いてて恥ずかしくないか？
それともそんなに完成されたスタイルなのか？

>>9
＞自明なことにはコメントは書く必要はない。
コメントとソースの解説を混同してないか？

>みたいなコメント書くやつ、ほんとにいるのには参るな。

たぶん自分用のメモなんだよね。。。

>>9
一番迷うのはどこまで自明としていいか?
なのよん。おおむね、後輩/新人がみてもわかるように
と考えると自然と多くなってしまう。
同僚を考慮すると減るんだけどね。
コメント多い人は周りのレベルが(orも)低いのかもかも。

/* (゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ

　　　　　　　　スレッド名：(゜д゜)ｳﾏｰ
　　　　　　　　機能概要：(゜д゜)ｳﾏｰなスレッド
　　　　　　　　引数 ：糞スレ職人1
　　　　　　　　戻り値：コピペ煽り厨房
　　　　　　　　修正履歴：
　　　　　　　　　　　　>>2 1の母登場
　　　　　　　　　　　　>>3 1の精子登場
　　　　　　　　　　　　>>4 1の主治医登場

(゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ(゜д゜)ｳﾏｰ */

>>24
いるいる。まじでいる。
「コメントをかけ」といわれてコメントの意味もわからず
とりあえずつけられそうなところから書いているようなヤツね。

「コメント書かない」っていうのは、論外として。

最低限、変数の宣言とメソッドの宣言、クラスの定義などはコメント
書け。

たとえば、なんらかのフォーマットを仕様として規定していると、
その仕様をきちんと「プログラム中」に書いてあると、
ソースを読むのが楽になる。

また、実装上不十分であるがこのシステムでは十分であるので
「仕様」として手が抜いてある部分などもきちんとコメント
すべき。

後は、例外が発生する時にどんな場合に例外が発生するのかとか。

この程度も書いてないソースなどクソ。逝ってよし。

うお、何気にコメントたくさん書くのって少数派なのか...
まぁいいさ、俺は工数と照らし合わせて書けるだけ書くさ。
金融系は一本のソースが何年もメンテされるってあるからな...

まさか
/* 変数A を１増加 */
A++;
なんて書く奴がいるとは思えないが…。

>>32

コメントの行で金もらえるようになれば認識は大きくかわるかも
ね。
うちはコメント書いても金もらえない。

33>

前のプロジェクトそうでした。

>>33
いるんだよなぁ・・・
しかも、変数名が「A」だったり「B」だったりで・・・

>>33 過去数々のコードレビューをこなしてきたが、どのプロジェクト
にも必ず実在します。↓とか。

agt.setAgentName("hogehoge"); // エージェント名を設定

>>34 最近はどこも人月計算なので行数稼いでも対価は変わらんな。
行数見るだけだったら全コードの半分以上はコメントだな、俺の場合
(javadoc の出力も納品物なんで)。

>>36

変数A,Bもイタイが適当に辞書から引いた英単語を使うのもイタイ。
かえって判りずらかったりする。
AでもBでもいいが代わりに日本語でコメントいれてほしい。

会社辞めるときに変数名を「fusianasan」「omaemona」
などにしておいたが、何か？

>>36
つうか、そんなソースがまかり通ってしまう管理状態が
問題。メンテで受けた仕事なら別だけど。

最低限のコーディング規約ぐらい作れ。コメントに
関しても。変数の命名に関しても。

>>39
お約束だが、逝ってよし。

>最近はどこも人月計算なので行数稼いでも対価は変わらんな。

その通りなのだが、その人月数は規模から求めるでしょ?
コメント無しの。

>>40
ｽﾏｿ.ｻﾝｷｭ.

>>33
コードレビューどころか「詳細仕様」と称して
ドキュメントに「変数Aをインクリメント」なんて
のが登場するフローチャートを書かせる馬鹿
がいた。

ちなみにそいつの書くプログラムはグローバル
バリバリの長大関数でコピーペーストでさらに
×30倍
そんなフロー書かせる癖にコメントは・・・・無し！

ちなみに怒りっぽい40歳独身主任。

>>33
以前（つっても随分昔）やったプロジェクトのコーディング規約でそんなのがあったよ。
　コード１ステップづつに必ずコメントをつけるコト
みたいなのが。ちなみにC言語。

他にも、
　C言語の１ステップづつに、コメントでBASICのコードを書くコト
なんてトンデモなコーディング規約もあった。
コメント書く工数がコーディングの数倍かかった。

たまにコメントが全部英語ってのも見かけますが、あれは
どんなもんなんでしょ？
自分、英語弱いからちんぷんかんぷん。

コメントは大事でしょ。
新人にまずやらせるのはいきなりコーディングするのではなく
最初にコメントを入れてどこで何をやるかを考えさせた上で
実際にコーディングさせるYO

簡単なHelloWorld的なものだったらそんなことやる必要ないけど
次のステップに進ませるときにやると効率としてはだいぶ変わってくるYO

http://w3.dreams.ne.jp/~pb1871/PracComments.html
http://w3.dreams.ne.jp/~pb1871/PracClassComments.html

eXtreme programming萌え
つーかXP導入する前からずっとこのスタンスだったけど。

>>45
そんなコーディング規約逝ってよし。
大体にして、コーディング規約っていうのは、参考にすべき
よい例が文書としてネットにも出回っているから、そういうの
を持ってきて、どうしても合わないところだけ改変して
利用すべき。

独自で作り出したコーディング規約ってろくでもないものが多い。

>>45
＞C言語の１ステップづつに、コメントでBASICのコードを書くコト

ﾌﾟｯ
みてみてぇ

>>40
ｉアプリだとそんなことも言ってられず・・・・。
鬱山車膿。

中規模なものになると、コメントが後々自分を助けるよね

>>46
別にいいんでは？
日本語読めない人がメンテする可能性を想定しているとしたら、
コメントも英語で書くのが当然。

>>51
iアプリって組み込み系とアプリ系のやなとこ取りってカンジですか？

僕の場合はコメントは関数やメソッドごとにつけるようにしています。
これは、関数の中身を見ずにソースを「眺める」だけで機能の概要を把握するためです。
ですから、このコメントは１行以内の日本語で大略的且つ簡潔に記述します。
関数の中身はなるべく英文に近くなるように書き、コメントは殆ど書きません。
このやり方を過去五年以上一貫していますが、五年前のソースでも今すぐに
読んで解釈できるので、それなりに効果のある方法だと思っています。

MS-ACCESS萌え〜
英語苦手小学生相手でもコメントいらねぇＹＯ！
Function 逝ってよし()
　　　　MsgBox "逝ってよし！"
End Function

コメントはちゃんと書けよコラ。
コメントはしょるやつは非常識。

私はイヤな客先業務では極力コメントをはしょります。

コメント書くのは当たり前だろ。
大きいプロジェクトなら必須。

>>54
どちらかと言うと、組み込みに近い感じ。
迫りくる10Kの壁、機種による実行メモリの少なさ、
表示に関しての機種依存。そのすべてを10kのなかに入れようとしたら
変数名をaとかbにしないとやってられない。
その分、コメントはしっかり入れる。

>>60
そういう場合は、元ソースとしてきちんとした変数名で
書いたものを用意して、そのあとコンパイルする前に
置換にかければよいのでは？

短いローカル変数名の命名規則まで決めておけばOK。

俺はコメント沢山書くぞ。なんせ詳細仕様書代わりだからな(藁

>>62
超ド級同意！

>>60
おいおい。
そんなのコンバータ通せよ

>>61,>>64
逝ってきます。

>>62
おいおい（藁
しかしプログラムを設計書に反映させる（藁
のが楽なので俺もたくさん書くぞ。

Ｊａｖａって、長い変数名を使うとコンパイル後のバイナリも大きくなるの？

>>67
変数ってローカルじゃないよね。
Javaに限らず、ある程度シンボル名等が実行モジュールに残る。
でないとOSのプログラムローダーがシンボルテーブルを作れないから等、
それぞれ正当な理由がある。当然その分だけサイズは大きくなるね。
だからコーディングルールに長さまで規定される場合があるのか？知らん。

んー、コメントあんまり書かないね。
後で見て必要と思われる部分は書くけど。あとロジックの意図したい事とか。
全てにコメントつけると後の解析時に混乱を招く恐れがあるからね。
インデントは揃ってないとやだ。

でも多人数で開発するものにはコメントつけまくりをせざるをえない。
プログラマだけが見るわけではないので。

コメを書く割り合いについて
優秀さとか見る人を誰に設定している時の話とか聞きたいな。

ソース公開する場合にコメ消す人いる？

>>67
コンパイル後のバイナリ？

>>70
当然、デバッグ系は消します。
ってあまり関係ないけど。

おまえら、あのNTつっくたカトラーをみろ。
まめにコメントつけてるぞ。
カトラーにマンセー。

カトラーがNT開発のときに使っていたのは主にアセンブリ言語では？
アセンブリ言語ではコードで意図を示すのは難しいですね。

高級言語で書かれたソースは、それ自体がコメントだろ？

やっぱりコメントの量は
年齢(またはプログラミング歴）に反比例するのでは？

学部二年のプログラミング演習のころが一番コメント量が多かった＞自分
しかし提出課題に詳細なコメントを付けていたのは自分一人。
演習の形式は、40人の学生が、完成したソースを一人のTA（ドクター）に見せて
チェックしてもらうというもの。前期はメダカ学校の教師、後期はスパゲッティ工場
の検査技士と化していたドクター（現在は講師）に敬礼！

いやカトラーはC言語だったと思うが。

数年間保守することも考えると、あるていどコメントが欲しいかも。
できれば仕様書も・・・

if (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)) { /* 閏年か? */
なんて書くくらいなら、コメント無しでも
if (IsLeapYear(year)) {
のほうがいいなあ。

最近、記憶力が悪くなって、スコープを外れたとたん前にやっていた処理を
忘れてしまうので、コメントをつけておくと便利。コーディングがはかどる。

っていうのは半分冗談だけど。
新人には、コメントを付けるように指導している。適切なコメントが
付けられないようなら、そもそもその処理自体がおかしい可能性が
あるからね。

コメントは実用に即して書こう！
まちがっても「できる人はコメントが少ないのさ！」なんてニヒルはやめてね。

出来る人がコメントが少ないとからって、
コメントが少ないからできるっ人て訳じゃない。

余談。以前「字がうまいヤツは理系じゃない」とか逝ってたヤツがいて、
「そんな理屈いってるオマエが理系じゃない」とｵﾓﾀ。

a = 120; /* a に120を代入する */

・・・死刑。

bound = 800; /* あとでちゃんとdefineする 95.12.24 */

なんだか寂しいコメントだった。

/**
*<pre>
*
*</pre>
*@param
*@return
*@exception
*@see
*@version
*@since
*@author
*/

仕様書は書かないけど、コメントは書くよ。

>>83
　（大爆笑）

>>79
＞できれば仕様書も・・・
おくゆかしいな

>>26
>わかるって事は違和感が無いって事だよな。
>10年前と同じレベルのソース書いてて恥ずかしくないか？

誰が10年前と同じレベルのソースを書いてるって言った？

あのさ、プログラマが書いたコードの通りコンピュータは
動くわけで、そのコードを書くプログラマがコードをみて
それがどう動くのかを想像できなくて、どうやってコードを
書くのよ。
だから、大前提として他人が書いたものであろうが、
自分が書いたものであろうが、わざとトリッキーな書き方
をしたものでないかぎり、ソースはだいたい読めなきゃ
だめなんだよ。

ましてや、この場合は自分で書いたものってことだろ？
それで分からないってのは健忘症モノじゃん。

（ちょっと煽り）

>>73
カトラーの書いたソースってどこで読めます？
ＮＴやＶＭＳはカトラーがソース書いてるわけじゃないですよね。

>>89
１さんって職場・人に恵まれてるから、コメントを書かなくても
いいんじゃないかと思います。

＞だから、大前提として他人が書いたものであろうが、
＞自分が書いたものであろうが、わざとトリッキーな書き方
＞をしたものでないかぎり、ソースはだいたい読めなきゃ
＞だめなんだよ。

わざとではなくトリッキーな書き方をしたソースは
よめなきゃだめですか？

なぜ素直に記述できなかったかをコメントに書くんだYO

>わざとではなくトリッキーな書き方をしたソースは
>よめなきゃだめですか？

よめないより読めるほうがいいだろう。。。

$flug = 1; #フラグに１をセットする

昔こんなのあった。アホか・・

アホなコメントはあっても困らん。
むしろ心を和ませてくれる為のギャグや愚痴を入れてくれ！
あったら困るコメントの例って無いのか？

flug.....
たしかに阿呆だ

>>93
しかもスペリング間違ってないか、それ？

>>94

/* 以下、馬鹿な客をダマス為に入れられた絶対に通ることの */
/* 無いロジック。◯◯さんの命令により挿入。なんでも見積 */
/* りとの差が大きかったようで、その対策 */

if ( DEBUG ){

コードを丹念に読めばわかるからかかないっていうのは死ね。

コードを読む際の補助としてもコメントは書くもんだ。
そのソースを読む人が、楽ができるように書くもんで、
自分が楽するために手を抜くなんていうのは論外。

そんな職場もいってよし。

わざわざ「aですよ」とは言えなかった・・。
ちなみにその人、ネスケを「ネットエスケープ」と言ってた。
これは教えてあげました。

>>94
＞あったら困るコメントの例って無いのか？

>>17 にも書いたけど、「ウソ」のコメント。
コードをちょっと読んでウソって分る程度なら可愛いけど、
ロジックが複雑なやつだとちょっとね…

ってこれってオレが時々やっちゃってるんだよね。
仕様変更があったときに、コメントはそのままにしちゃうパターン。

俺はあんまりコメントいらないと思うが。
staticじゃない関数や変数は仕様書に書くからコメントの必要はないし。

趣味で書くプログラムだってＣ等なら4〜５００行の関数なら
コメント無くても大差無いし、長い関数は大抵単純な処理が多いし。
自分のコードも２年位前のコードを読む事あるが、別にコメント
読まないでコード読んじゃうけどなぁ。

今w3mのコードいじってるけど、これもあんましコメント無いけど、
俺はあんまり困ってない。

後で読む人の為にコメント、というが、本当に仕様書じゃ足りない？
俺が書くのは、staticな変数で仕様書には書かないけどそのモジュール
内ではいろんな所で呼ばれる変数で、名前からだけじゃ全部の役割が想像
出来ないような奴位だけど。

コメントは的確に、かつ簡潔にお願いします〜
お願いです。先輩がた・・・・
先輩には判るかもだけど、私には解りません〜〜
後生ですからぁ〜
あと、英語のコメントは勘弁してください〜

コードと同じ情報しか持たないコメントはあったら困るコメントだ。
コードとコメントを同期させなくてはならないという手間が生じる。

コメント英文でつけるのはかまわんが和英辞典なんか引くな。
「dispose」という単語がむやみに出てくるので何かと思って聞いたら
「処理する」を和英辞典で引いたらこの単語が出てたんだそうだ。
ごみ処理でもするのか。

コメントを全く書かない人も困り者だと思われ

俺はアウトローなのでコメントなんて書かないぜ！

コメントなんて、棒線でいいんだよ。
記号だよ記号。

>カトラーの書いたソースってどこで読めます？

「闘うプログラマー」にカトラーのコメントに関する記述があるので、
そのことじゃないですかね。別にソースを読んだわけじゃないでしょう。

>ＮＴやＶＭＳはカトラーがソース書いてるわけじゃないですよね。

いいえ、書いてますよ。といっても今のNTやVMSにどれだけカトラーの書いた
コードが残っているのか疑問ですけど。

コメント不要派は他人のソースメンテしたことがないのか？

>>109
きっと、作り逃げ専門なんですよ
もしくは、自分も苦労したから他人も苦労させようという小さい人間

>>109
他人のソース面手するなら、コメント読むな！
嘘ばっかり書いてあって、修正個所を見誤る。

>>109
同意

大体書かない奴ってドキュメントもろくでもなし。

>>109
腕のいいプログラマのコードは、
コメントがなくても読むのに困らない。

ヘボいプログラマのコードは
コメントもクソなので、一概にあるほうが良いとも言えない。

見事な煽りだ。>>109

結局、自分のプログラムはキレイだと思ってるDQNはコメント書かない事が分かった。

Javaでは入れなきゃ、JavaDoc作れん(^^;

自分はプログラムがへたなので、せめてコメントだけでも充実させようと思って
努力してきましたが、おまえのコメントはない方が良いねと言われました。
努力だけは認めてください。

コメントをまったく書かないやつは糞だと思う。
でも「コンパイルできるコメントを書く」という努力をしないで成長が
止まっているやつも使えない部類に入る

>>117
プログラム以前にコメントをちゃんと書けてるかな

コメント大量に書くけど、ポイントを全然得てない
文章で意味が通じない、って人がたまにいるけど

>>101
さらっと書いてるけど、４００から５００行の関数なんてつくんなよ。
その時点でだめだめだよ。コメント以前の問題だろ。

>>120
同意

昨日やった作業も覚えてないのに、
コメントなしでは生きていけません。

鬱だ...。

1000行超の関数を解析して泣きそうになった事ならあるよ･･･

１ファイルで２万行にも及ぶ main.cのメンテ...関数が計70個。
そんなの書く奴だから変数名はa1,a2,a3とかだし、
もちろんコメントは一切ないし、大量の広域フラグ変数だらけで関数の引数は全部今で言う(void)。
Sun3時代だからコンパイルが長いこと長いこと。
作った野郎はとっくにおいしい仕事に逃亡して知らん顔。
人生で初めて殺意って奴を覚えさせてもらいました。

おいシギ○ラ、てめぇだヴォケ！氏ね。

久しぶりに思い出して腹が立って書いちまった。ｽﾏｿ。

この前、全行にコメントが書いてあるプログラムを発見！
バカじゃねーの？

一通りコーディングした後コメントをつけてったら、
どうにもコメントできない処理が出てきやがった。
見直したらコーディングミスだったんだけど、
コメントつけてよかったと思ったよ。

あと、どんなに本人がうまい！と思ったコードでも、
所詮他人に見せたら意味不明なものになるから、コメントは必要。
全行にコメントあったって、無いよりはよっぽどいいと思う。

>>109
>コメント不要派は他人のソースメンテしたことがないのか？

結構、強烈なやつを触ったことが2,3度ある。

・元がBASICで、それをそのままCに書き直したやつ。
もう気が遠くなりそうな数のグローバル変数とgotoの嵐の
4000行のルーチンをちゃんとC++に書き直してやった。
Cだと構造体を使うようなデータが全部配列になってて、
変数の意味が分かったところで、それを意味の分かり
やすいマクロに置き換えて少しずつ書き直して、全体の意味が
分かったところで、C++で一から書き直した。

・Win95用のVXD,16bitDLLとそのサンクDLLが混在した、
ディスク回りのユーティリティソフト。

これには一切コメントが無かったが、ソースを何度も
眺めながら、Win95DDKを必死で読んで、ファイルシステム関係
の資料をWEBで探して2ヵ月かかってやっと新たに機能を追加
できる自信がついて、1ヵ月で求められる機能を追加した。
このソフトはそこそこ出回ってるから、あなたも使ったことが
あるかもしれない。

>>125
ハゲしく同意。
全行コメントなんて無いも同然。

平均５０行以下で関数つくって、
関数ごとにコメントがあれば十分だと思うが、どうか。

>>129
そのたうり。
おいらは単純平均取ったら1メソッド10〜20行くらいで書くぞ。

>>90
>わざとではなくトリッキーな書き方をしたソースは
>よめなきゃだめですか？

過去にどうしてもさっぱり意味の分からないソースに
出会ったことがあって、挫折したことがあるから
「わざとトリッキーな書き方をしたものでないかぎり、」
なんて断りを付け加えたわけなんだな。

それはプログラマ厨房だった1年目のころに暇だったので
lexの吐いたCのソースを読んだときのこと。
全然、初期化されていない変数をいきなり使ってるところが
あって、これってバグの元じゃないか？なんて思ったが、
静的な変数は0で初期化されることを知ったきっかけでもある。

まあ、当時はDFAとか全然知らなかったから、今なら読めるかも
しれないが。

関数の行数少なくして階層深い方がよっぽど読みにくいと思うが

凄いPGは、コメントを書かないわけではなく、
また、書き方を知らないわけでもなく、
常に不要だとも思っていない。
ソースが洗練された結果、書くべきコメント
というものが減ってしまっただけだ。
# もちろん、書くべきコメントと書かない方がいい
# コメントの区別が出来ている。
# コメントが多すぎるとソースの洗練が足りないと感じる。

と想像するが如何。

ソースがいくら洗練されようとも、読む側のレベルが一定じゃないんだから
コーディングした人間がいくらソースすですべてが完璧に理解できると
思い込んでても、コメントは書くべき。
趣味で書いてて自分でしか見直さないってんなら、不要かも知れんけどな。

>>132
機能分割/関数命名の上手下手によると思うが。
上手いなら関数はわけた方がわかりやすい。
下手なら意味があちこちでぶったぎられてて
わけんほうがええ。

>>134
オレもそう思います、かなり。

>>133
アルゴリズムがシンプルかつ十分で、変数名、関数名が意味を正確に反映していたら、
コメントは関数毎で充分だとおもう。
※まだ洩れはそこまで巧くソース書けないから、コメント書き散らしてるけど(藁

>>134
*十分に*洗練されたソースを読んで理解できない人間が
そのプログラムに対して何をするつもりですか？

世のプログラマの8割はへたくそだ。
とりあえず、コメントは多めにつけとけ。
自信過剰のおまえらに言っても無駄だろうけど。

>>134
＞趣味で書いてて自分でしか見直さないってんなら、不要かも知れんけどな。

一週間も放っておくと自分の書いたコードだって理解不能になる場合があるので
趣味コードだからと逝ってコメントが不要なわけでもない。つーか、趣味の場合は
仕様書なんて書かないので余計、コメントを入れる方がいいのさ。
書き捨てのコードでも昔似たようなコード書いたなあと確認した場合に助かる場合が
あるのでコメントは書いたほうがいいかも。

#昔、自分が書いたコメントなしのわけのわからんコードを読み直したとき、
#きちんと考えて書いてたじゃん、オレ。と分かったときは空しかったなあ。

>>137　アルゴリズムがシンプルかつ十分で、変数名、関数名が意味を正確に反映していたら、

世の中そう単純なら良いんだがな。
画面周りの浅いコードだけなら良いんだよ。
でもな、そーゆー訳にもいかんだろーが。

関数は普通はドキュメント書くんだから、コメントは
いらないと思うんだが。

>>142
ドキュメントに書く場合でもソースに残せ。
何年もたったあとで、ドキュメントが紛失していることなんてざら。
ソースからドキュメントの雛型を自動生成するくらいの気合でやれ。

使用言語の差が発言の差になってないか？
Javaのメソッド 平均３行以下
Cの関数 平均２０行程度 (俺ソースの平均)
じゃメソッド(関数)単位のコメントの意味が違いすぎる

昔の環境ではコメントのせいでコードが読めなくてうざかった。
640*480程度で文字数は40*25くらいか・・。あと
int funcA(){
}
｝カッコの部分の改行についての議論やってたＢＢＳ見て面白かった。
勿論僕は改行減らし派だったけど、そのうち両方に馴れた。
エディタがコメント表示／非表示を選択できるよーにしてくれ〜。
他の人はプリントアウトしてた利したけどカッコ悪くて真似る気なし。
とかいいつつ・・・周りの意見が絶対だし名ぁ

>>145
どっちでもいいのでは？

俺は、パラメータが多くて改行するときなんかは｛の前で改行
入れるし、そうでないときは入れない。つまり

int funcA(param1,
　　　　　　param2,
　　　　　　param3,)
{
}

int funcA() {
}

というかんじ。

かんすうないにfor文とかが間に入ってきたとき、統一性が
保たれない、という意見がその板で出ていたかと思います。

｛と｝、書いたコードを見返したとき、数が合わなくて
一瞬どきっとする、とかそういう話しなんでしょうか？
エディタ辺りが色分けしてくれてるとわかりやすいっぽいけど、
そういうのは抵触ある人も多そう。
字下げだけではちょっと紛らわしい事も多いですから。
特に他人の書いたものを見たときなんかは・・・。

>>141
> >>137　アルゴリズムがシンプルかつ十分で、変数名、関数名が意味を正確に
> 反映していたら、
>
> 世の中そう単純なら良いんだがな。

そうそう。
その処理が、何を意図して、どのようなトレードオフ関係の落とし所として
そうなっているかが自明であれば、コメント量は最小限で良いのだけれども、
世の中、その自明で常識はずな前提条件がすぐ変るから困るんだよな。

結局のところ、コードがどのような処理をしているかは、コンピュータは
書いてあるとおりにしか動かないから、ある意味、コメントがなくても自明
なのだけど、設計者が何を意図して、どのようなトレードオフを検討した結果
そうなったかについては、自明でない。

理由が分からないけど、自明な処理がいっぱいのコードってありますよね。
その当時は、常識であったハードウエアやライブラリのバグを回避するため
とか、その当時のハードウエアのアーキテクチャに基づいたクールな最適化を
行っているとか、タイミングを取っているとか、理由がわかっていれば、今と
なっては書き直した方が良いのだけれども、至る所にそんな部分があって、
ちょっと手をつけられないコード。本当、困るよ。

誰もそういうことにコメント書かないとは書いてないと思うが

>>138
仕事で触らなきゃいけないときってあるじゃん。

>>142
そのドキュメントって関数内のアルゴリズムまで記述するんですか？
インターフェース（仕様）くらいしか書いたこと無いです。

>>150
>>138は学生だから現実を知らないの(ﾌﾟ

インプリメンテーションについてソースとは別のドキュメント（詳細設計仕様書とか呼ばれてるやつ）を
作りたがるのは昔の名残だな。ソースはパンチャに出さなくてはいけなかったし
英大文字と数字と記号しか使えなかったので日本人にはソースコメントに説明なんか書けなかったのだ。
今では意義がないのに日本人だけがPADだのSPDだの考案して書きたがってる。
二重管理になって手間ばっかりかかる。だからインド人に負けちゃうんだよ。
インタフェースはドキュメントは必要だがそれ以上の詳細はソースコードとコメントで十分。
でも年配者が牛耳ってるような会社ではこういうリクツはまったく通じないね。

「このまっくすばふさいず(MAXBUFSIZE)てなにする定数ですか」
と聞かれて
//一時記憶用に確保するメモリの最大値
なんてコメントを入れたことがあるよ。

分かるはず。なんて思い込みはいけないね。
コメントって大事だとつくづく思った。

関数名や変数名を「名は体を表す」風にしてくれるのはいいんだけど
和英辞書引くのは止めて。

他の人がソース追うときに英和辞書引けって事??

Javaだと変数名は略さずに書きます。

IDEを使ってれば長い変数もへっちゃら、
可読性はあがる。

>>155
昔はともかく、いまはCでも略さないよ。たぶん.．な。

>>氷魚
あんた某スレじゃずいぶん叩かれているらしいが
けっこう、まともじゃないかい。

>>154
だけど、たくさん関数作っていると、ちゃんとした英語で記述したくならない？

俺は電子辞書使っているから英和も和英もすぐ引けるので
利用しまくっている。
英語の勉強にもなるんだよ。

関数ヘッダに関数の意味書いておくから許して。

ごめん、
コメントは英語と日本語のチャンポンだ。

人に見せる直前に、日本語に翻訳してる。

＞二重管理になって手間ばっかりかかる。だからインド人に負けちゃうんだよ。

ソース内にドキュメントも内包してしまうのは基本だよね。


俺は再利用可能な関数を作った場合
ネットに公開できるような質でＦＡＱやＴｉｐｓを書くようにしている。
数が増えると、かなり楽しい。

数年間、今の言語に触っていないとすべてを忘却しそうなので
ドキュは大切だよ。

>>134は真理

>>159

英語のライブラリみてるとき
英語でたくさんコメントが書いてあったんだけど
それが読めなくて欝になりました。

ソース修正したならコメントも修正してくれ。
修正前のソースは素直にコメントアウトして残しておいてくれ。

コメント書かない理屈の一つとして、
コメントと実際のコードとが同期してないことがあるよね。

俺の場合、あくまで読みやすくするためにコメント入れておいて
仕様的なことは、別のドキュメントに書くよ。

〜をするみたいなコメントは嘘になる可能性があるから書かない。

関数名や変数名、クラス名が、意味を持った名前になるようにする。

まとまった処理を、ここからここまでで一仕事ですよってかんじで
適当に空行を入れとく。

こんなもんかな。
もちろん、特別な理由があって変なコードを書いてるときは
説明を入れるよ。
でも、変なコードを書くよりは、わかりやすくて素直なコードに
直すことの方が多いけどね。

モジュール単位で責任を持って開発してるから、
きちっとした外部インタフェース仕様書と
開発者ノートがあれば、十分なのだ。

とりあえず１０年くらいやってるけど、
コメントについて文句を言われたことはないね。

カトラーのコメントて会津大学の連中てソース公開しているので
読めるんじゃないかな。
たしかに闘うプログラマーで"カトラはコメントに熱心だ”という
記述からです。
win2000でカーネル総書き換えしているのでカトラーのコードはほとんど無いのでしょう。

カトラーも年取って丸くなったのでしょうか

コメントを書く・書かないの是非はともかくとして、

コメント書かない派はちゃんと本音を言うべきだと思う

要するに、めんどくさいんでしょ。

面倒くさい事を喜んでやるのは馬鹿。効果とのトレードオフ
だから無ければ困る事しか書かないってことじゃん。

多ければよいとか、少ないほうがよいとか、
そういう問題じゃないだろ。

すべての行にコメントする奴も、
コメント無しの奴も、ペアで逝ってよし！。

>>162
>修正前のソースは素直にコメントアウトして残しておいてくれ。

いやです。

>>162
VSS,CVSなどのバージョン管理ツールを導入して幸せになりましょう

>>170
まったくだ。コメントアウトしてゴミを残す奴は叱ってます。
あと、頼むからあちこちに日付と修正者名を書き散らかすな。
そんなもの履歴を見れば全部わかる。

コメントはほしいですね。
書き込みを見てると、腕の良いプログラマはコメントがなくても読める
（理解できる）と書いてる人いますが、腕が悪くても理解するのはだれ
でもできます。ただし、膨大な時間を要することになるだけ。
業務でやる場合には、工数というものがあるので、ソースを読む
のにそんなに膨大な時間をかけてるわけにはいかないと。
コメントがあれば流し読みで理解できるものが、コメントがなくソースが
汚い（トリッキー）であるばっかりに、何日もかかってしまうこともあります。
時間の無駄としか思えません。
ちなみに私は、関数＆グローバル変数＆ローカル変数のロジック制御を
行う変数には、必ずコメントを入れます。
また、上記以外のコメントは、ソースを読むときの邪魔にならないように
ソースの行の右端っこに寄せて書いています。つまり、コメントを読みたく
ないなら、ソースの右側に目線をもってかなければ、コメントのないソース
を読んでるのと同じ感じになるようにしています。

ちょっと複雑かなというところにはコメントを入れて欲しいが
誰でもわかるところに大量に長文コメントがあるのは返って邪
魔なときがある。

>>172
それって結局、本当の意味での「仕様書」を書くときに
プロジェクトメンバー皆で決めることじゃないのか？
共同作業なら、プロジェクトメンバーで決めることだろ？

>>174
自分で後で見たら変な分になってた。
しかし、スパゲティコード多いな。

コメントは地図なんだよ。
情報が多すぎてもわかりにくいし、少なすぎても頼りない。

>>171

こういう人、どう思います？
http://mentai.2ch.net/test/read.cgi?bbs=prog&key=992527661&st=93&to=94

どうって...
93は正論、94は厨房。

>>178
厨房だけど、削除するときはさくっとするよ。

>>172
>>腕のよいプログラマはコメントがなくても読める
のではなく、
腕のよいプログラマはコメントの必要のない程度に綺麗なコードを書く
だと思う。

プログラムのコメントはコメントが必要な時に入っていれば良い
後で自分で読んでもわからないようなコメントは問題外
美しいプログラム（整理された）を書こうよ。

エラーメッセージにここへＴＥＬするようにと電話番号を表示する
プログラムはやめようね。後を引き継いだものがめいわくするから

例えばどこぞの開発チームに加わったとして、自分以外で一番綺麗かつ実用
的なコードを書く方に、変数・関数の命名規則を合わせる。
（自分が一番まともだと直感したとしたら・・・それはある意味地獄）
長いものを多く好む派、短いものを多く好む派、とか今でも結構ありますか？
tmp、ptrとか僕はこういうものの方が好きだけど、違う方もいたみたい。
コメントの書き方も同様。自分でいちいち考えた事なかったり。
そのせいで僕はとっかかりは他の人より遅い事多かったですけど。

・・・これで自分一人に非難が来るようだとかなり痛い職場と判断可。
ただ・・能力的に足りてなかったらその限りに有らず、っぽい。

バグフィックスの事を考えたりしたら、せめて意見を交わせるチーム内
だけでも一定の書き方、みたいなのが欲しいけど、場所によっては無視
っぽい。けど・・・後から一括で手直しする職場とかもあるのかな？
/*これ全部Ｃでの話です。Ｃ++は殆ど無知だからわかりません。
　Ｊａｖａはビルダーのふぁうんでーしょん？を軽くいじった後放棄*/

改修の仕事の場合なんかだと
ｺﾒﾝﾄ多いと助かります

だて、ﾁﾗてみればわかるし。

// コメント書いていいですか？

>>181
○○　○○ Memorial Errorなんてものがあった。
なんのメモリアルだよ、ｳﾞｫｹ。

>>183
改修に改修を重ねたプロジェクトだと、コメントがそもそも信用できない
なんてコトも多々...鬱だ...

やっぱりXPの時代だな。

>>174
私の環境では、ひとつのプログラムが数十年使われつづける
こともしばしば。ですから、プロジェクトメンバーといっても、この間に
人材の流動が起こります。そうすると、引継ぎに引継ぎを重ねて、
小さな引継ぎ漏れが、そのうち大きくなってくることがあります。
「仕様書」も、もちろんＤＢ資料化して毎回更新しますが、かなり古い
システムの仕様書って、資料にならないものが多々あるので、
やはり、プログラムレベルにも、資料を残してあったほうがやりやすい
です。当然、仕様変更の際は、コメントを修正することを忘れないように
しないといけないですけど。

>>180
揚げ足をとるみたいだけど。
今回のネタは、コメント。つまり、読む側の立場になって書かないとまずい
のでは？
>腕のよいプログラマはコメントの必要のない程度に綺麗なコードを書くだと思う。
これは「書くとき」のお話だとおもうんですが・・・。

内容とコメントが一致していないという人もいますが、コメントを見つつ
それをもとにソースを読んでロジックの確認をするのが普通だと思う
ですけど・・・。どう？

ばかな…。ソースを読んでて意図が解らないところはコメントを見る、でしょ。
だから、そういうところにコメントが必要なんだってば。

ﾀﾏにさｺﾒﾝﾄに

/* これでいいのか？ */

って書いてあるんだけどこんなｸｿｿｰｽどうしろというのよ？

>>185
ﾜﾗﾀ

>>188
＞内容とコメントが一致していないという人もいますが、コメントを見つつ
＞それをもとにソースを読んでロジックの確認をするのが普通だと思う
＞ですけど・・・。どう？

そのとおり。

でも、
結局コメントもソースも読まなければいけないので、二度手間です。
読み手に着目させたいところ以外はコメントを書かない方が
よい場合が多い（と考えてる）わけです。

コメントを書かない派の中には、
・自明的なコードを書く人
・コメントが間違っていると嘘を書くことになるのでわざと書かない人
・ドキュメントに詳しいことを書いてあるのでコードには書かない人
・コピペしてきたので原点がわからないようにコメントを削除する人
・面倒なので書かない人
がいます。

２／４／５はともかく、書かない派の人だって、基本的には
必要なとこには書きます。

>>190
それはリファクタリングしなさいということだと思う
おれも
//かっこよくないので思いつきしだい直すこと
とか書くし

>>193
自分の書いたソースには責任を持つべし。
自信がなければその時点で誰かに相談すべきでは？

>>193
趣旨には賛同するが、そのコメント内容はいただけないな。
せめて何が問題か書き残しといてくれ。

俺は関数の先頭に機能やわかりにくそうな変数の役割を書いておく
だけだけど。あと特殊な処理をしているときも簡単に説明を書いておく。
だめですか？

>>196
それが普通だと思ふ。
過剰なコメントは関数が長くなって処理が把握しにくくなる。

>>197
関数内にはほとんどコメントを入れないってことなんですが、
ふつうでしょうか？
あたりまえだけど、関数は極力１００行以内に抑えるけど。

内容についてコメントしなきゃいけないような処理のブロックが
あったら、関数として切り出してしまうというのは異常でしょうか？

関数が50行を超える事が滅多に無いのですが、おかしいですか?
static関数はたくさん作りますよ。名前こそ全てってか。

関数に切り出すのはやりすぎでは？

普通だと思うにょ。

関数の長さは長すぎなければ自由だと思うぞよ。
int add(int a,int b) {
　return a+b;
}
みたいなのはかんべんダケド。

オレはだいたい60%の関数が10行以内、
95%が30行以内、50行を超える関数はおそらく0.1%以下。

自分の場合は関数の長さにはこだわらない。
構造化に役立たなければ関数に切り出さない。
よって１００行越えることも。
ただその場合はコメントをしっかり入れる。
ローカル変数も一部でしか使わないなら{}のブロックで宣言する。
/*１．変数の初期化 */
初期化処理

/*２．グラフの罫線描画 */
描画処理

/*３．グラフプロット */
{
int x,y,color;
プロット処理
}

みたいに。
１回しか使わない関数だったら関数化する意味がないと思わん？

僕が作る関数は関数のネストを深くしたくないので、
１関数あたりの行数は少なくないと思います。

どのあたりでバランスとればいいんだろうか…？

みなさん関数のStep数の話してますが
それは言語は何ですか？
C？
それとも一般的に短いのが好ましいの？

>>205
いや、意味あると思う。
１００行の中から（例えインデントしてあっても）
例でいうところの１，２，３のコメントを拾い読む苦労より
連続して３行にまとまってた方が、その関数としては見通しが
いいと思う。
ただ、長さにはあまりこだわらないのは同感。
レイヤ分けを明確に。と思ってる。

>>205
stlの<algorithm>を知らないでしょ？
それと、デザインパターンのような抽象度が高い
ものの価値が分からないでしょ？

>>205
君、他人のソース読む経験が足りない。
それはいわゆる「クソソース」と言うんだ。

長い関数ほど、メンテがしにくい。
一度しか呼ばれなくても、関数化してくれた方がいい場合が世の中にはたくさんある。

>>208
でもそういうスタイルだと関数を呼ぶだけの関数が山のように出来ない？
そんで、たくさんある細かい関数が、目で見てわかる処理の
どの部分をどこまで請け負ってるのかｻﾊﾟｰﾘわからんとか。
grepやらで追っかけるのがめちゃくちゃ大変。
ちゃんと起承転結がコメントしてある長い関数の方が分かり易いって。

>>211
それはなー「程度の問題」なんだよ

それがプログラミングってもんだ(藁
起承転結が関数名に現れてるでしょ。

>>211
APIやクラスライブラリの使い方を示すための
サンプルソースであれば、

>ちゃんと起承転結がコメントしてある長い関数の方が分かり易いって。

ということは認めてあげよう。それと沢山関数があると
プリントアウトしたときソースが読みにくいということも
あるだろう。

だけど、むやみやたらと関数を増やしたものではなくて、
その関数の責任範囲が明確で、ロジックの正当性が自明
であるようなシンプルな処理に構造化されたソースの
メリットは読みやすい以上にソースの再利用が効いて
融通が効くということなんだと思うけどな。

>>209
知らないです。

でも抽象度を高めるってことは再利用するってことでしょ？

俺が言うのは
「再利用の必要もなく、構造化も出来ない関数ってのが生ま
れるのはケースによっては必然。その結果長くなるなら、そ
れは本質的に長い関数。よって分割して細かくしても本質的
には変わらない。ローカル変数が減らせるってメリットも関
数内に{}ブロックを作ってそこで宣言すればいい。」
ってこと。

再利用性がないのにステップ数にこだわって分割するって話だよね。
＞＞214

>知らないです。
素直でよろしい。

>「再利用の必要もなく、構造化も出来ない関数ってのが生ま
>れるのはケースによっては必然。その結果長くなるなら、そ

もう本当に、絶対に、死んでも再利用されない処理ならば、
あなたの言うことにも理はあると思うよ。
書き捨てのプログラムなんかはそういうこともあるし、
あるいは、switch-caseで、caseの節がムチャクチャ多い
ケースでなおかつテーブル引きをしない理由がある場合とか
関数は長くなることもやむを得ない。

しかし、それが本当に再利用できないものかをよく考えて
みなよ。そうすると100行を超えるロジックなんか
ほとんどないと思うぞ。

stlの<algorithm>とかみてみなよ。とてもチャチい処理
ばっかりだけど、こういうレベルでのソースの再利用が
できるということは、他人に伝えるのが難しい概念を
抽象度が高くて複雑な概念を意味する語彙を使って
より短い言葉で的確に他人に伝えることが出来るという
ことと同じなんだと思うぞ。

うんにゃ。まずはメンテナンスコストを下げる為。

>>215
構造化も出来ない関数が必然って、具体的にどんな場合？
教授ちょ。

関数が増えると逆に解りづらくなるよね。
オーバーヘッドかかるし。

だから何百行の関数でも俺はＯＫ。
Windowsのメッセージ処理組んでいると数百行は軽く超えるよ。

>>219
＞Windowsのメッセージ処理組んでいると数百行は軽く超えるよ。

　それは単にビギナーなだけのような気がします。

　オーバーヘッドは
　人間のという意味であれば、ツールとか工夫で改善できると思うし
　CPUのという意味であれば、記述の仕方で改善できると思うし

GUIに関していえば
関数呼び出しが数段はいったところでたいした性能差はないと思われ。

チリも積もれば山となる。
まあ実行時の話よりソース優先は最近の傾向だから別にいいけど。

>>222
性能シビアな要件のとこでなければ、そういう
オーバーヘッドを考えるのはNext Stepで、
まずは保守性とか考えて書くのがいいんでないかい。
結構そこまで求められるケースは特殊だと思う夜。
それにそこまで必要ならジャンプコストやcaseの順序も気になるし。

どんな理由があろうとも300行以上の関数は見たくない。
関数呼び出しのオーバーヘッドが気になるくらいなら
呼び出すライブラリの見直し、最適化の方がはるかに効果的と思われ。

他人のコードをチェックしてたときに、
「あんまり深く考えないでくれ〜」って部分に当たった事有り。
多分なんらかのアルゴリズムの為のコード部分。コメントぜろ。
当然読み飛ばしたけど・・・・こういう部分はそもそも表にサラスなよ〜！

他には・・・。
コードは完璧な綺麗さを保ち、コメントも文句ない丁寧さ。
けど、実用性が低いコード・・・今まで見た中で一番空しかったコード。
それ書いた方に職に対する適性がなかったといえばそれまでだけど。
文句はつけようもなかったけど却ってそれだけに辛かったりして。
しかす・・・全くの他人事でもないわな。

>>219
自分のヘボさをさらけ出してるだけだね。
金貰ってるなら脳味噌つかえ。

>>219
オーバーヘッドが気になるならinlineにしとけよ。
数百行になるのはやっぱり未熟だからだよ。
Windowsだからってのは全然理由になっていない。
初心者がSDKでプロシージャが数百行になるってのなら
わからんでもないが。そのレベルなの？

コメントにつまらんこと書くな。

でもなー
客先が、コメントしか読まず、ソースを読解しようとするのは
はらがたつ。
わかるわけねーから、質問してくるが、
その度に、「ソースを読め」（を翻訳した言葉で）と言っている。
コメントはある程度書くけど、あんましコメントに執着されても
困る。

>>227
では君はメッセージのハンドリングをどう処理するのかね？

switch(msg){
case WM_MOUSEMOVE:
MouseMove(param);
break;
case WM_SIZE:
:
:
:
延々
};

結局、フローさえ解りやすければ行数なんてどうでもいいことなんだよ。
メッセージと関数ポインタとのペアを作るって手もあるが、
そっちの方がよほど面倒になるよ。

>>230
＞メッセージと関数ポインタとのペアを作るって手

わかってんじゃん。これでいいよ。

ふーん、「構造化」って関数を短くしさえすればいいんだ。

#include <windowsx.h>

だから名前が大事なんだって何度も何度も何度もいってるでしょ-が。
これが解らんやつにこれ以上サービスするつもりもないけど

>230
>メッセージと関数ポインタとのペアを作るって手もあるが、
>そっちの方がよほど面倒になるよ。

そうしろよ。どっちがすぐれてるかもわからんのか？
オーバーヘッド気にしてるくせに、プロシージャにswitch使ってるのは
厨房すぎるぞ。

>>46
コメントを英語で書くっつうのは、英語版も後で作るかもしれん時だな。
ちなみに、ソース中にSJISコードが混じっているC++ソースを
英語版のコンパイラでビルドすると、通らないことがあるので注意しませう。
２バイト目が、「\」になっているコードなどだな。
なんだっけなー「十」とかがそうだったけか。

>>235
テーブルジャンプの方が速いことも多いぞ。

>>236
べつにC++に限らずMS-Cの時代からあった現象だぞ。
MS-Cの場合は-Jをオプションをつけてコンパイルしたら
よいのだ。

>>238
へーそれは氏欄かったな。
英語版VC++でも -J オプションでいいの？
しかしなぁ、多言語マルチプラットちゅう場合もけっこあるからなぁ。

>>237
この場合はプロシージャが長い場合のことでしょ。
何百行もつづく場合は遅いだろ。

switch-caseで書いたとき、その数の条件分岐の羅列に展開する
コンパイラなどいまどきないだろう（最適化すれば）。
case値の範囲に応じてテーブルを勝手に作ってくれるから
自分で書いたテーブルよりメンテしやすいし、
俺はswitch-caseのほうをおすすめするよ。

でも、関数テーブル作ると、メッセージｘ状態でマトリックス作れる
から、メンテが楽なんだよねぇ。
ってWinのメッセージとはあまり関係ない話、スマソ。

コメントを書くのはバカ高い掛け金をかける保険みたいだな。
死ななきゃ保険など無駄。ノーコメントﾏﾝｾｰ

作り逃げ専門か？
ま、勝手にしろや

>>244
ハンドルからして>>243はネタじゃないの？

>>241
条件分岐の羅列のほうが速い時もけっこうあるよ。

あげ２

コピーして関数名と変数名だけを置き換えた関数が山ほどあるのを見たとき。
実質その２つは同じ関数だろう。

//文章だとわかりにくいか...すまそ。.

>>248
きっと変数が全部グローバルなんだろ(藁

話の流れ関係なくて悪いけど、、、
半角/全角キーを押すのが面倒だからって理由だけで友人がコメントを英語で書いてよこします。。。
ええ、英語読めない私が厨房ですよ（鬱

いや、ドキュメント英語でも読むけどね、そりゃ。