どうしても Doxygen で出力しなきゃならないわけ？

１つのバグを修正するのに１ソースの１箇所の変更だけでは済まないこと多いよね
バグの修正は複数ファイルの複数箇所が同時に変更されてはじめて成立する。
Doxygen のコメント形式で、ある１箇所の修正履歴を見ても/見ることができても
俺としては、それだけではぜんぜんまったくうれしくない。

そういう履歴はソースコード管理ツールを正しく運用することで得るものだ、と
俺は思うわけ。

修正履歴をソースコードの中に埋めるのは筋違いだ。

ウチでは CVS の $Log$ タグは使用禁止令を出してるくらい。

バグ修正のような履歴が大きいなので、出力しなくてもいいと思います。
関数単位に関して修正履歴を出力したいだけですけど。。。
例：
/*********************************************************
* @brief テスト関数
* @param[in] int iFoo 意味なし
* @return なし
* @date 2009/2/1
* @author 太郎
* 2009/2/2 次郎 引数チェック機能を追加
**/
void foo( int iFoo)
{}

上記通り、2009/2/2 次郎 引数チェック機能を追加の履歴はdoxygenで出力できません
か？　できれば、方法を教えてくれませんか。

@dateは複数書けるようです。（1.5.1-p1を使用）
/**
* @date 2009/02/02 新規作成
* @date 2009/02/02 変更（by maru）
*/

私も
> 修正履歴をソースコードの中に埋めるのは筋違いだ。
とは思いますが...

@dateは複数書ければ対応できました。
ありがとう。

> 修正履歴をソースコードの中に埋めるのは筋違いだ。
ソースは新規ではなく、十年以上前からずっと変更と新規がありましたら、
ソースに修正履歴を埋め込まないと、理解できないと思います。

修正履歴をソース中に埋めこむことの是非はちょっと脇に置いといて。

> 関数単位に関して修正履歴を出力したいだけですけど。。。
> 例：
> /*********************************************************
(中略)
> * 2009/2/2 次郎 引数チェック機能を追加
> **/

この例のように、地の文に履歴を書くと何か不都合があるのでしょうか。
地の文とは別の形式にして目立たせたい、というのなら、

修正履歴:
- 2009/2/2 次郎 引数チェック機能を追加

のように、リストにしてしまうという手もあります。

<余談>
で、修正履歴をソース中に埋めこむことについて。

> ソースは新規ではなく、十年以上前からずっと変更と新規がありました
ら、
> ソースに修正履歴を埋め込まないと、理解できないと思います。

それを管理するためにCVS、VSS、SVN等のバージョン管理ツールが
あるのだと思うのですが。
私の場合、ソース中に修正履歴埋め込まれていてもあまり役に立たない
ことが多いです。
履歴を見たい時は、変更内容の要約の他に具体的なソースの差分も欲しく
なるので、結局バージョン管理システム頼りになりますから。
過去のソースを全部コメントで残せば一応ソース単体で履歴を辿れない
こともないですが、これ、読み辛さが半端じゃなくなるので、一番
やって欲しくないことです。

まあ、バグ修正履歴ではなく、関数の仕様変更履歴くらいなら
ソース中に(というか、doxygenのコメントに)書くのもありだと思います。
仕様変更だけならそれほど膨大にはならないでしょうし、ドキュメントに、
「バージョンxx→yyでは、～のように仕様が変わった」
と書かれていればそれはそれで便利かも。
</余談>

yoh2さん、見解は大賛成です。
しかし、十年前からはじめたソース改訂ルールは、私たちが従うしかありません。でしょう？

そんな古臭いルールは見直しの時期なのでは？という言い方も出来るわけで。

> yoh2さん、見解は大賛成です。

おっと、そうでしたか。
バージョン管理ツールを使うより、ソース中に履歴を埋め込んだ方が
よいという考えをお持ちだと思い、逆(と思っていた)立場から
意見を述べてみたのですが、どうやら誤解のようでしたね。申し訳ないで
す。

> しかし、十年前からはじめたソース改訂ルールは、私たちが従うしかあり
ません。でしょう？

従うしかないか否かは環境によっても異なってくるでしょうから、
同意も否定もできません。
従わなくてはならない、ということに対して反例があるか、という
問いならば「反例がある」となりますけどね。
バージョン管理ツール未導入のDOS時代からのソースも生き残っている
私の勤務先では、ルールが昔と変わっていますから。

> しかし、十年前からはじめたソース改訂ルールは、私たちが従うしかあり
> ません。でしょう？

　十年前からはじめたソース改訂ルールに従うのは、今出来るとこまでで
　いいと思います。
　あとDoxygenに頼らずに現状の正当の方法でソースコード管理ツールを使うことも
　考えたほうがいいと思います。
　まえ、そうしていたからといっていつまでもその方法をとおすのもどうか
　と思います。

皆様、ありがとうございました。

本件は、単純な技術問題ではなく、管理ルールに関連がありますね。
ルール変更に関しまして、PMと全員に納得させる必要があります。
（説得能力も必要ですね）

本件は、完了にしました。