東方算程譚

コメントを追加

# re: どーも釈然としない 2008/02/27 10:00 T.Hirase

日付名前入りコメントを打ち込む必要があるかどうかは置いといて、
日付名前入りコメントを打ち込みたいなら、
マクロエクスプローラ内にある「InsertDate」辺りをカスタムすれば良いかと。
（[Samples]-[VSEditor]-[InsertDate]）

# re: どーも釈然としない 2008/02/27 10:08 シャノン

軍曹の話を思い出した。

# re: どーも釈然としない 2008/02/27 10:08 K5

今の案件のコード規約がこれです。
コメントアウトのほうが正規のコードより多くなってます。
読めたもんじゃありません。

バグを埋め込んだのかがわかるのが重要らしいですよ。
その人の腕がどの程度がわかるように…

# （笑） 2008/02/27 10:10 Out of Memory

（笑）

# re: どーも釈然としない 2008/02/27 10:13 επιστημη

僕がこれを強いられたら

// 2008.02.27 えぴ (ここから)
#if 0
いまあるコードを全部抹殺
...
#endif
いまあるコードから署名コメントをぜーんぶ
とっぱらって短ぁくお掃除ののち修正
// 2008.02.27 えぴ (ざまーみろ)

てやりそ ^^;

# re: どーも釈然としない 2008/02/27 10:25 ゆーち

あちこちの仕事で、このような指示を受けました。
ほとんど無視してきました（ｗ
問題となる行の対策場所が、その行の前後だけだという前提になってるってのが問題なんですけどね～。

責任の所在がわかると、最後に修正した人（下請け会社）に無償で対応させようというハラですね。
以前のコードに問題があったことは、棚上げです（ｗ

# re: どーも釈然としない 2008/02/27 10:27 ゆーち

あ。思い出した。
スタッフにこいつを指示したことがあります。＿|￣|○

そんときは、自分のテスト不足ソースを渡したんで、自分がどこをミスってたかをあとから把握するためにお願いしたんでした。

もちろん、そのまま放置ですが（ｗ

# re: どーも釈然としない 2008/02/27 10:31 Ognac

"有効なステートメントには必ずコメントをつけろ"という規約があったりします。
// ▼ 2008/02/27 ○山×男 コーディング
a = b + c ; // aに bにcを加えたものを代入する
d = b * c ; // dに bとcの乗算を代入する
// ▲
開発者当人は、「コメントの価値がないし、書く内容もないが、かかなければ規約違反で受納してくれない.....目をつぶって書いている。はずかしい。」と言っていた。冗長な作業を強いる上流者が全体の足を引っ張っているんでしょうね。

# re: どーも釈然としない 2008/02/27 10:33 まさる

バージョン管理システムが無いところで、エディタでソース呼んだときに変更履歴が分かるからとか。

というか、バージョン管理システムを使いこなせてない（使ってない？）から、こんなのが上から降ってくるのかなぁ。

＃修正履歴が溜まると、いい加減いらいらしてきますです。

# re: どーも釈然としない 2008/02/27 10:34 επιστημη

> 責任の所在がわかると、最後に修正した人(下請け会社)に無償で対応させようというハラですね。

あー、そんな使いみちがあったか。
けどさ、原因とその修正箇所は往々にして一致しないっしょ。
さらにバグ埋めたヒトと掘り起こしたヒトと直したヒト(と埋め戻したヒト)も一致しませんよねぇ。

# re: どーも釈然としない 2008/02/27 10:36 やまだ

動いているうちには、問題ないんですけどね。
なんかバグのでたときは、
　　// 2008.02.27 えぴ (ここから)
　　// 2008.02.20 やまだ (ここから)
より、
　　// 2008.01.25 やまだ (ここから)
　　// 2008.01.16 えぴ (ここから)
を疑え、ってな感じで使うみたいですよ。
あいつのコードの方が信用ならん、って感じで。
あとは、あの人が書いたコードには迂闊に手を出すな、と(苦笑)。

> 僕がこれを強いられたら
んでも、さらにその外側に #ifdef つけられて、結局わけがわからなくなるですよ。
実際、#if 1 と #if 0 のネストとか見たことありますし。なにがしたいんだか……。

以前、リファクタリングしましょう、ってお仕事があったんですが、その大半は余計なコメント消すことだったりしました。
「いや、その辺は経緯がわからなくなるから置いておいてくれ」、って抵抗勢力がいましたね。

# re: どーも釈然としない 2008/02/27 10:37 まさる

Typo 「呼んだ」→「読んだ」

# re: どーも釈然としない 2008/02/27 10:38 επιστημη

> バージョン管理システムが無いところで、エディタでソース呼んだときに変更履歴が分かるからとか。

それなら一段下にディレクトリ掘って
history/process.cpp.20080220
history/process.cpp.20080224
history/process.cpp.20080227
みたいに丸コピー残した方がよっぽどマシに思えちゃうです。
diffかけりゃ差分でるんだし。

# re: どーも釈然としない 2008/02/27 10:40 まさる

＞diffかけりゃ差分でるんだし。
偉い人はdiffの存在すら知らないんですよ、きっと。

# re: どーも釈然としない 2008/02/27 10:42 επιστημη

うははは、盛り上がる盛り上がる♪
みなさんよほど欝憤を溜めてるとﾐﾀ
# ガス抜きにお使いください > ココ

# re: どーも釈然としない 2008/02/27 10:58 K5

実を言うと、このコメントのほうがコード打つより多くて
IDE使わないでテキストエディタで作業してます…

VC6のインテリセンスが使えないってのも原因の一つでもあるんですが、今の時代逆行しすぎorz

# re: どーも釈然としない 2008/02/27 11:03 επιστημη

> んでも、さらにその外側に #ifdef つけられて、結局わけがわからなくなるですよ。
> 実際、#if 1 と #if 0 のネストとか見たことありますし。なにがしたいんだか……。

「やられたらやりかえす！」

コード中の"屁の役にも立たん"コメントで
撹乱されるくらいなら追い出します。

# その前にお上と徹底抗戦かな。

# re: どーも釈然としない 2008/02/27 11:05 がる

いいぢゃないですか「修正できる」だけ。
「正常系でかつ再現性100%のバグ」以外は全部後回しにされるよりは orz orz orz

ちなみに。「後日」は「後日」。ええ明日という日が永遠に明日であるのと同じくらいの意味合いで「後日」です orz

# re: どーも釈然としない 2008/02/27 11:09 よねけん

>> バージョン管理システムが無いところで、エディタでソース呼んだときに変更履歴が分かるからとか。
>
> それなら一段下にディレクトリ掘って
> history/process.cpp.20080220
> history/process.cpp.20080224
> history/process.cpp.20080227
> みたいに丸コピー残した方がよっぽどマシに思えちゃうです。
> diffかけりゃ差分でるんだし。

私が新人の頃、バージョン管理システムを知らなかったので、このような方法で対応していました。
＃今でも簡易的なものはこの方法で対応しちゃいますが。
当時Windows環境で便利に使える無償のdiffツールを見つけられなかったので、Linuxマシンにアップロードしてdiff使ってました。
全手動バージョン管理システムwww

# re: どーも釈然としない 2008/02/27 11:20 Mr.T

Mr.Tです、こんにちは。
Accessなんかで開発していることは、
こういうの結構ありました。

最近はそうでもなくなったんですが、
ソース履歴を置いとく方法ってなかったも同然で、
テキストに吐き出して差分とってとか、やるのも手間がかかったです。

でもまあ、そんなのつけてもどうせ見ないんだけどね(^^;

# re: どーも釈然としない 2008/02/27 11:41 kox

以前の現場での話。
バージョン管理システムを使えばいいで片付く内容なので、
それがないという前提で。

問題の箇所に履歴が残っていないと、
以前からそのままだったのか、修正してそのようになったのかが分からない。
そして、その修正内容が、
バグなのか、仕様変更でそうなったのか（責任の所在を）はっきりさせるために使用していた。
動きが以前と違うということでソースを見たら、仕様変更扱いで修正されていた。
（ユーザも複数人いると、自分が関わらない仕様変更には無頓着だったりする）

そんな理由でコメントを残していましたよ。

# re: どーも釈然としない 2008/02/27 11:50 επιστημη

んー...バージョン管理システム使ってない、
あるいはその頃の名残なんだろけどさ。
それにしても

/*
修正履歴
2008.02.23 ぽぴ 新規作成
2008.02.25 えぴ 機能追加(仕様書#17225-12)
2008.02.27 えぴ 不具合修正(インシデント780-1-23)
*/

みたいなんをファイルなり関数のアタマに書くんじゃダメなんすかね?
そこまでしてコードを管理コメントで汚したいですかね?

# re: どーも釈然としない 2008/02/27 12:09 Blue

> マクロエクスプローラ内にある「InsertDate」辺りをカスタムすれば良いかと。
は、その掲示板で私が提案しました。
それで質問者は解決したようです。

>みたいなんをファイルなり関数のアタマに書くんじゃダメなんすかね?
ですね。

# re: どーも釈然としない 2008/02/27 12:14 めたぼ なら

脱線系ですいませんが...
> いいぢゃないですか「修正できる」だけ。
> 「正常系でかつ再現性100%のバグ」以外は全部後回しにされるよりは orz orz orz

私の知り合いが、以前<del>大手都市銀行</del>金融系のシステム開発に携わっていたのですが、まさに同様の状態だったそうです。
COBOLで超スパゲッティ！
いつも「修正したい！修正したい！」が口癖でした。

見方を変えると...
COBOLでオブジェクト指向(?)
ソースが全部見えてるのに、ブラックボックス扱いで、テストケースが通れば問題ないと...

こんな事やってるから、ちょっとしたシステム変更で大コケするのよね。

# re: どーも釈然としない 2008/02/27 12:27 とっちゃん

うちの署名コメントは、変更箇所に理由を書くために使ってますね。
仕様変更とかでｗ
ソースのトップに書いてる人はいない気がするな。

仕様変更と言っても、仕様書が変わったじゃなくて、動作をこう変えてくれ～なので
うちの仕様はすべて動作仕様ですからねｗ


過去に実際にあった悲惨な例では...
打ち合わせなどなどで、変更することに決定->実装->動作を見る->やっぱり元に戻して->は？
なんてパターンが...トラウマになるくらいにはありますｗ

ええ。過去に何人もが何度「も」泣かされてます。

なので、仕様変更を伴うコードの修正は、すごく敏感。
前のは安全策で残しつつ...なんてことになります。

もう自己保全の世界です。
ま、中には４つも５つも前のバージョンと同じに...なんてのもありますが...
＃さすがにそんなに古いのは残ってないのが大半です...


ま、バグ修正は、手元の環境で治ったことが確認できればコメントアウトしたソースは消してアップが
ほとんどですけどねｗ
＃たまに忘れて残ったままなどということが...ｗ

# re: どーも釈然としない 2008/02/27 12:30 凪瀬

定期的に話題に上がりますね。コレは。
業界にはびこる悪習ですよね。
http://blogs.wankuma.com/nagise/archive/2007/10/16/102359.aspx

あぁ、前回は４か月前になるのか。

# re: どーも釈然としない 2008/02/27 13:13 うどん

ブチ切れそうになるので、
// <うどん> コメント整理 2008.02.22
とかやって、まとめて消してます。

#if 0
#if 0
#else
#endif
#else
#endif
とかこんな状態なの「ばっかり」

# re: どーも釈然としない 2008/02/27 13:26 επιστημη

> // <うどん> コメント整理 2008.02.22
> とかやって、まとめて消してます。

それが許されるならハナっからやんなきゃいーのに
なんだけどねー

# re: どーも釈然としない 2008/02/27 13:51 よねけん

バージョン管理システムを使えばOKとか変に安心しきるのもどうかと思う。正しく運用されなければ害悪にすらなる。
(ファイルサーバでの管理の場合、作業ミスで削除してしまったり、ファイルサーバが逝ってしまったりということを普通に考慮するのに、バージョン管理システムを使うようになると何故か他人まかせになるのはなぜだろう。)

・チェックインしようと思ったら、排他制御がかかっていたからとそのファイルを削除してから、新規ファイルとしてチェックインされた。
　→そのソースの過去の履歴が消滅。
・チェックアウトしたまま退職した。
　→どうやって解除すればいいの？
・開発完了して本番開始して数年後にバージョン管理システムの入ったサーバのハードディスクが逝った。バックアップはない。
　→そのプロジェクトのドキュメント、ソース一式すべて消滅

バージョン管理システムについて、プロジェクト関係者すべてが知識を持つべきだし、運用指針に関して言えば、プロジェクトレベルではなく会社レベルで持ってくれ・・・と言いたい。

その辺、みなさんきちんと運用されているんでしょうか。
＃上記の事例は実際に目にしてきた事例ですorz

# re: どーも釈然としない 2008/02/27 13:52 シャノン

C# って救世主じゃね？

#region ここから、見なくていいコメント
#endregion // ここまで

# re: どーも釈然としない 2008/02/27 15:33 凪瀬

バージョン管理システムを使えばそれで完璧というわけでもないけど、
ソース上のコメントに記すやり方はバージョンを管理することすらできてないですから。

バージョン管理システムを使った上で起きた問題は、
ソースコメント方式で回避できるというなら議論の余地はあるけども。

# re: どーも釈然としない 2008/02/27 15:35 まさる

＞その辺、みなさんきちんと運用されているんでしょうか。
会社レベルどころか、プロジェクトレベルでさえ怪しいです・・・
というか、ちゃんと使えてる人間は数えるほどしかいないような。

Tracとかもそうなんですけど、こういったツールって使いこなせれば、とてつもなく強力なのに、なかなかそうならないんですよね。

# re: どーも釈然としない 2008/02/27 17:17 れい

私は別に嫌いじゃないですね。
既に動いているものを若干手直しするだけなら有用かと思います。
変更点がたくさんあるなら全部見直して過去コメント削除ですね。

署名は、責任の所在というよりも、
「何をしてるのかわからないときに訊くべき人」
を示してるのではないかと。

バージョン管理システムはいい方法ですが、
ローレベルな記録を残す価値はあると思います。
バージョン管理システムが壊れても、
最新ソースが一つあればわかるわけですから。
ソースファイルのみ配布の場合もあるし。

# re: どーも釈然としない 2008/02/27 17:46 しゅんた

初歩的な質問で申し訳ありません。
コメントっていったい誰のため/何のために必要なのでしょうか？
これに尽きるように思います・・・

# re: どーも釈然としない 2008/02/27 18:03 Ognac

変更者に問いあわせようにも実装者が外部の人間のケースが多いので実質無意味では。
さも内部要員のように記載するのは尚更悪い希ガス。

# re: どーも釈然としない 2008/02/27 19:19 シャノン

> コメントっていったい誰のため/何のために必要なのでしょうか？

以前、凪瀬さんが考察されてましたけど、コメントと一口に言ってもいろんなコメントがあるので、一概には言えないと思います。
で、この釈然としないコメントについて言うならば、どうも、現場のプログラマのためではないように見えますね。

# re: どーも釈然としない 2008/02/27 20:32 れい

Ognacさん
> 変更者に問いあわせようにも実装者が外部の人間のケースが多いので実質無意味では。
シャノンさん
> どうも、現場のプログラマのためではないように見えますね。

他の方もですが、業務としてコーディングする現場のプログラマからみて有害なのは納得です。

ソースがパブリックドメインだったり、一子相伝的なものだったりする場合には、コメントでしか変更点が伝達できないんですよね。
そういう状況では往々にしてコード全体をきちんと理解してる人は殆どいなくて。

何人かに一人、何世代かに一人がソースを綺麗になおす。
後任はそれをごまかして使う。
問題があれば前任に個人的に連絡をする。
前任者は個人的時間を使ってそれに答える社会的義務がある。
そんな世界では、コメントの名前と日付が貴重なのです。

もちろん、ソースを綺麗に直す人の評価は低く、
ごまかして使う人の評価は高いんですが。

# re: どーも釈然としない 2008/02/27 23:08 裏口

これって多分メインフレーム系COBOLの名残ですわ。

#　慣れ親しんだ老兵だけに通じる慣習ですが、ソースコード
#　自体の履歴管理が可能な場合、不要だと思いますよ。

# re: どーも釈然としない 2008/02/28 14:41 しゅんた

ジャノンさん、ご回答どうもありがとうございました。
なるほどです。
現場のプログラマ用なら、そんな余計なコメントはいらないですよね。
プログラムの意味が分かれば言い訳だし。
ちなみに自分は作業環境上あまりコメントは書かないでも
済んじゃいます。(^_^;)
自分があとでメンテするときになどに参考になる程度の
コメントしか書きません。

# re: どーも釈然としない 2008/02/28 23:40 よねけん

凪瀬さん
> バージョン管理システムを使えばそれで完璧というわけでもないけど、
> ソース上のコメントに記すやり方はバージョンを管理することすらできてないですから。

このトピの主旨とはずれちゃいますが、
こういうトピに対していつもバージョン管理システム使えばOKなところで話が終わっているのが多いと感じているので、
じゃあ、バージョン管理システムを使う上での前提条件とか、(開発時、保守時それぞれでの)運用上の注意事項とかが話題になっているのを見たことがないなぁと思った次第です。

# re: どーも釈然としない 2008/02/29 0:55 THREE-ONE

バージョン管理しないんだったら
・変更の趣旨、内容を別ドキュメントに
・変更前ソース（必要分）
・変更後ソース（必要分）
をまとめてディレクトリに格納。
ついでに ID でも採番してディレクトリ名にでも。
なんてやれば管理も追うのも結構楽だと思うんですけどね。

# re: どーも釈然としない 2008/02/29 1:06 とおりすがった人

http://www.geekpage.jp/blog/?id=2007/10/22
この話を思い出した

「今までそうしてたから」っていう理由しかないと思う。思考停止に絶望する今日この頃

タイトル		タイトルを入力してください
名前		名前を入力してください
URL
コメント   コメントを入力してください
名前をブラウザに記憶する