/.Jに聞け：コメントにおける変なルールって？ 128
ストーリー by hylom
コメントは動作に影響がないからこそ好き勝手やり放題 部門より
コメントは動作に影響がないからこそ好き勝手やり放題 部門より
insiderman 曰く、
ブログ「日々常々」で、「変更前をコメントアウトして残す」というバカバカしい習慣が紹介されている。
例として挙げられているのは、「コメントを削除する場合その旨をコメントとして残す」という例。
// 2012/08/15 irof 修正開始
//// 2012/07/21 削除開始
//// // 間違ったコメント
//// 2012/07/21 削除終了
// 2012/07/21 irof 削除開始
// // 間違ったコメント
// 2012/07/21 irof 削除終了
// 2012/08/15 irof 修正終了
someMethod(arg);見るだけで笑えてしまうが、実際コメントに変更履歴を残す習慣が残っているところはまだ多いのでは？ 有識者の皆様に、「変なコメントルール」をうかがいたいところである。
不幸のソース (スコア:5, おもしろおかしい)
退職してから４年振りに前職で８年間担当していたソースを見た。
そこには…
// このソースは不幸のソースです。
// 関わった人は皆辞めて行きます
別に私のせいではないけど後任が皆長続きしなかったらしい。
え？やっぱり私のソースのせい？
私のソースが駄目だから辞めた訳では無い…はず…orz
ばかだな (スコア:4, おもしろおかしい)
行数増やした方が料金とれることもしらないのか？
急いで対応したら特急料金な
Re:ばかだな (スコア:2)
えっ。これっておもおかなの？
Re:ばかだな (スコア:2, おもしろおかしい)
いや、すば洞とか参考になるとか付いてもちょっと。。
VCS使ってないなら (スコア:2, 興味深い)
まあ仕方ないと思わなくもなくもなくもないけど(VCS使っていない事自体がダメすぎてとっとと逃げる算段を計るけど)、VCS使ってまでソースをゴミで埋めたがるんだからマジで何やってるのか意味分からない。
# いちおうソースコードの管理について意見を出せる立場だったので反対してみたけどダメだった
Subversion使ってるけど (スコア:2, 興味深い)
私も昔は今回のストーリーのような話を聞いたときは鼻で笑ってたものなのですが…
今受けてるプロジェクトは、上の意向でSubversionで管理してるのですが、このストーリーのネタほどではないにしても、基本的に削除修正でも削除したことを示すコメントを半ば自主的に残してます。
「仕様書では○○することになってる」ものを「口頭で△△にするように指示をうけ」たりしたときに、言質を取る意味が大きいですかね。
あとで「動作が仕様通りの○○になってないんですけど」って言われたりするんだもん
1行単位の修正ごとにコミットしていけば、コード上は削除してしまってもいいんだろうけど、
「テスト済のコードしかコミットしちゃダメ」っていうので、ある程度まとめてコミットするしかない状況で…
ファイル単位でしかログが残せないというのは、コミットログの粒度が荒すぎます。
(「△△のため、削除」したところもあれば「△△にするため、□□を追加」したところもあったりして、それぞれ個別にコメントを残したい)
Re:Subversion使ってるけど (スコア:2, すばらしい洞察)
まあ、別にいいんじゃないですかね。
目的は「分かりやすくて運用しやすい」でしょうから、杓子定規にする必要はないと思います。
とにかく全部残せ！は思考停止でナンセンスですが、とにかく残すな！も同様かと。
Re:Subversion使ってるけど (スコア:2)
仕様書改版させるべき。
たとえソースにメモしてても「言った言わない」の範疇だし、受け入れテスト担当はそんなことは知らんから。
で、コミットログだけど...diff取って該当部分に理由を書くとか、gitでやっといてsvnなブランチにマージするときcommitもコメントもまとめるとか...かなぁ...。
Re: (スコア:0)
修正した項目ごとに、行番号とか関数とかをログに書けば良いのでは？
Re:Subversion使ってるけど (スコア:1)
つ「Subversion」
Subversionは集中リポジトリ型だから「コミット」と言ったら「公開リポジトリへのコミット」なのさ。
分散リポジトリにするsvkっつーのはあるんだけど、あれはツールと言うよりハックだからgit使うほうがいいと思う。
Re:VCS使ってないなら (スコア:1)
VCSありかつコードのコメントアウト禁止というルールで開発をやってたことがありますが、
どうしてもやってしまう人がいました。
削除し忘れたと言うんですが、そもそもなんでコメントアウトしておくのかと聞いてみると、
適当に修正してテストしてOKだったらcommitするというやり方をしているそうです。
要するに原因を突き止めて対策を練ってから修正するのではなくて、行き当たりばったりなんですね。
とりあえず、そういうやり方ならコードのコメントアウトは便利だと納得はしました。
コメントの意味も含めてコードレビューをすれば、最終的にはコードのコメントアウトを削除できるはずです。
このコードには意味があってとってあると言われたら、検証済みか/検証手順は整備されているか聞けば良いでしょう。
レビューしないような環境なら好きなようにやらせてあげようよ。
コメントでも追うことが出来れば (スコア:2)
いろいろとコメントがごちゃごちゃ書いてあるけど、結局なにがどうなって現時点でどうなっているのかがよくわからないコメントにお目にかかったことが何度かある。
コメント内容から今どうなっているのかが分かるだけまだマシなのかも知れない。
Re:コメントでも追うことが出来れば (スコア:2)
私が担当しているシステムには、下記のようにコメンがありますが、見事にXとYが入れ替わってるソースがあります。
＃しかも2か所同じようなものがあるが、片方は正しく書いてあるという・・・（笑）
＃元からコメントは参考程度にしかならない(画面コピーしかない設計書も役に立たないのでソース読め状態)ので誰も（私も含めて）コメントを書き換える人がいない（笑）
Select Value
Case 1 //X-Aです
Case 2 //X-Bです
Case 10 //Y-Aです
Case 11 //Y-Bです
End Select
コメントに変更履歴を残す習慣をなくすには (スコア:1)
どんなツールが便利か議論した方がいいでしょう。
Re:コメントに変更履歴を残す習慣をなくすには (スコア:3)
VCSを使っているにも関わらず「コードを変更する場合は変更前の部分をコメントで残しておけ」というルールが存在する例もありますよ（汗）。
「コメントアウトのほうが差し戻すときに楽だから」「削除しちゃうと修正前がどんなだったか確認しやすいから」とかいう理由で。
theInsiderman（-1:フレームの元）
Re: (スコア:0)
VCSの履歴をコメントに展開してくれるツールがあればいい？
Re:コメントに変更履歴を残す習慣をなくすには (スコア:1)
こっちは機械系で政府に図面を全部出して認可もらう業界…有り体にいっていわゆる防衛産業だけど、昔は図面にすべての変更履歴が観覧できる必要があったけど、今はそんなことないぞ。形体管理する特別な図面以外は書類で確認ができれば（過去の図面が全部残っていて、容易に判別ができれば）問題ないことになってる。
これに組み込むソフトウエアも同様の管理体系だけど問題になってない。
未だにそんな感じで管理しているところってどこ？
Re:コメントに変更履歴を残す習慣をなくすには (スコア:1)
メインフレーマーには意外とVCSがないような気がするんですが。
Re:コメントに変更履歴を残す習慣をなくすには (スコア:1)
SCCSはメインフレーム由来と聞いた。
大昔、国産メインフレームの凄く高機能そうな(そして運用が難しそうな)VCSのカタログを見たことがある。
Re:コメントに変更履歴を残す習慣をなくすには (スコア:1)
SNOBOLで開発された [wikipedia.org]のだとか。いいなあSNOBOL。
Re: (スコア:0)
自分はvimなので開始行でma --- (マークA)
終了行まで移動して:'a,.s/^/\/\// --- (マークA行からここまで行頭を//に置き換え）
ってやりますが他の方は・・・
ってそういう意味じゃなくて？
ちなみに削除は 'a,.s/..// --- (マークA行からここまで行頭2文字をなしに)
そもそも (スコア:1, 荒らし)
この話がいったいどういうことなのか理解出来ない＼(^o^)／
誰かサッカーで例えてください。
Re:そもそも (スコア:2)
・反則したら、物理的にイエローカードをもらう。
・次の試合にでたら「あ、前のイエローカード、間違えたから」と言われつつも、そのイエローカードは持たされて、そのカードに「無効」と書かれる。
・で、また次の試合に出たら、「無効にしたの、間違ってた。やっぱりイエローね」とかいわれて、無効の文字が二重線とかで消される。無効の文字は読める。
・で、次の試合で反則して、イエロー出たんだけれど、いったい何枚累積しているのか誰もわからない。
#かえってわかりにくい(^_^;
Re:そもそも (スコア:1)
前の試合までに着たユニフォームを重ね着して試合に出るようなもの
Re:そもそも (スコア:1)
大量のフーリガンがフィールド内に乱入したまま、退場させずに試合続行。
フーリガン：選手比は１０：１以上。
しかもフーリガンは各自が応援しているチームのユニフォームと酷似した服を
着ているため、選手とフーリガンは胸の名札の色でしか判別できない。
＃自分のチームの選手の顔くらいは覚えているが、敵チームを遠目で
＃瞬時に判断するのは不可能なレベル．
みたいな感じとか。
クレイジー。
『行数が変わるので』コメント禁止！ (スコア:1)
ソフト操作の指導に行く自分は修正を行う際に、
「急な修正の際、電話で客に修正点をしてもらうので修正してもコメント行付与するな！」と厳命されています。
明確な仕様の策定とデバッグしっかりしてれば電話修正（笑）なんて不要だと思うのですが、ホント滅茶苦茶です。
----- ド素人につき突っ込み歓迎 アルミ製なので叩くと凹みます
Re:『行数が変わるので』コメント禁止！ (スコア:2)
自分だったら手元ではコメント付きのソースをVCSに入れておいて、提出用はフィルタでコメント削除、ってなことをしますね。
BASICからアセンブラへ移ったときには、実行環境のメモリを圧迫せずにコメント入れ放題で喜んだものだけどなあ。
１ステートメント - １コメント (スコア:1)
コードの内容はフィクションですが、ほぼ、こんな感じのソースを実際に見た。
まったくわかってないな (スコア:1)
ソースコードとの差分を渡して｢正社員にチェックイン」してもらわないとならない環境ってのもあるんだよ。
タイトルだけ見て (スコア:0)
「踏み逃げ禁止」とか系の話かと思ったら全然違った
Re:タイトルだけ見て (スコア:2)
わたしはてっきり携帯軍曹物語かと思いました。
http://homepage3.nifty.com/HIGUCHI/blog38.html [nifty.com]
あれ？ むかしは笑っていられたのに、いま読み返すと目からヘンな汁が…
Re:タイトルだけ見て (スコア:2, おもしろおかしい)
dondongaです
から書き出すとかそんなのかと思った
Re:タイトルだけ見て (スコア:1)
////// ○年○月○日 修正
//// dodongaです。
//// ○年○月○日 修正
// dodongaです。
// ○年○月○日 修正
…
こうだろ (スコア:1)
////// dodongaです。
//////
////// ○年○月○日 修正
//// dodongaです。
////
//// ○年○月○日 修正
// dodongaです。
//
// ○年○月○日 修正
////// --
////// 以上、駄文でした。
//// --
//// 以上、駄文でした。
// --
// 閑話休題
呼ばれたようなのでコメント (スコア:1)
dodongaです。
「お前のコメントにはゴミがある」
ってよく言われたけど敢えて無視して主張を通してました。
あのぉ～、それはdoxgenコメントです。
内心： ドキュメントがまともでないからだよ。設計書もなく、現場で直すからだよ！！。
あ、そっちの？それはバ～ジョン管理のためのコメントです。
机に戻る
あれ？doxgenが落ちた？
内心： ・・・・・・・・・・・・・・doxgenがオ～バフロ～起こす程のソ～スってなによw
追記：
その会社はもう辞めたけどね￥＾＾
閑話休題
Re:タイトルだけ見て (スコア:1)
Re:タイトルだけ見て (スコア:1)
コメントは「おはよう」「こんにちは」「こんばんは」のどれかから始めてください。
#bot対策だそうな。
アホな仕事 (スコア:0)
コーディングした本人じゃないと対処できないから。
品質とか効率とか以前に、組織的に正常な業務体制が構築されていない証だね。
Re:アホな仕事 (スコア:1)
blameじゃ足りない事があるんだよ。
特定のファイルの、行を弄った人とリビジョンが知りたいんじゃないんだよ。
不特定のファイルの、ある機能に関する複数revまたがっている修正で。その修正時点からの前後ｎ回文の修正を、ぱっと見たいんだよ！
別にいいんですよ。 blame して、 １つ１つ確認すれば特定できますから。
そのために。１時間かかったことありますけどね！
だから「バージョン管理しているから大丈夫」なんて私のクチからは、言えない。
もちろんそんな苦しんだ事は、過去２、３回しかありませんけどね。
ただしコメントで記録取るなら「どこかで綺麗にするフェーズ」を必ず設けるべきとも思っています。
ところで。なんだかんだで辿り着いた結果が。
「心当たりあるやつ！ 前にでろ！ 歯を食いしばれ！」
と。実に幸福なコミュニケーションを取る風景でした。
ログこねくり回すより関係者全員に声かけちゃったほうが効率的ですよ。
作業者の頭で「ひょっとしたら別件のコレと絡んでるかも」とか手を上げる人も居ますし
声かけるぐらい大して時間かからんので。 ログ追いかけは、その後でもいいと思ってます。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re:アホな仕事 (スコア:2)
ひでえ。
その一声でたくさんの人の仕事を止める事に罪悪感は無いのか？
一人で一時間で調べられるなら多分そっちの方がいい。
研究分野では (スコア:0)
前いた研究室では、コメント文は変更前コード、テストコード、#defineスイッチ以外ほとんど見かけなかったよ
昔々 (スコア:0)
年号が2012ではなく、19XXの頃ならこういうのが多かったですね。
ソースコード管理システム自体、あまり普及してませんでしたから。
元記事にはないですが、修正担当者の名前も残します。
Re:例を見て (スコア:3, おもしろおかしい)
要出展
ということは、「どこへエキシビジョンあるいはプレゼンテーションすればいいんですか？」というお話ですか？
Re:例を見て (スコア:1)
なつやすみの宿題は漢字の書きとりからだな
# あぁ、あそこへ行っていたのか。なら納得
Re:タイムカードの代わり (スコア:1)
糞なVCSを避けるのもプロジェクト管理には必要なことさ。
Re:日本語コメントはEUC-JPで書け (スコア:2)
JISやSJISはSCCSでは使えなかったとかが背景かも。
Re:日本語コメントはEUC-JPで書け (スコア:2)
違う文字コードにするのが普通なの？？？
＃なんでそんな面倒なことを・・・
Re:日本語コメントはEUC-JPで書け (スコア:1)
日本語コメント（だけ）はEUC-JPで書けってんなら、バイナリエディタでやるしかないな
Re:日本語コメントはEUC-JPで書け (スコア:1)
今時はソースの文字コードがなんでも、コンパイル後のバイナリにはUnicodeに変換された文字列を格納する環境多いですよね。
#変換されると知らずに以前痛い目にあった事がある
Re:謎ルール (スコア:5, おもしろおかしい)
こんな感じのバグ除けおまじないコメントを必ず埋める人がいたのを思い出した。
// (o_ _)o†(o_ _)o†┏┛神┗┓†o(_ _o)†o(_ _o)
// (o_ _)o†(o_ _)o†┏┛神┗┓†o(_ _o)†o(_ _o)
// (o_ _)o†(o_ _)o†┏┛神┗┓†o(_ _o)†o(_ _o)
当然要らないのでその人が現場から去った後に一度コメントを全削除したところ、何故かテストでエラーが出る怪現象が発生して結局放置する羽目に。オカルト怖い……。