コミットコメントの書き方(続き)

先日のコミットコメントの書き方(我流)に対して、twitter でコメントをいただきました。

BTS連携があればチケット番号も

[subversion]いいね! 僕はBTSと連携させることが多いので、太括弧【】の部分がチケット番号 #XX になりまする。連携できないときはこうしてみようかな / コミットコメントの書き方(我流) - 地平線に行く

http://twitter.com/kaorun55/status/7460414770118657

確かにチケット番号あった方がいいですね・・・。
それに、コミットコメント欄に書くよりもBTSに詳細を書く方が、読みやすそうです。
(コメント欄は Wiki フォーマットが使えないので、あまり長く書くとメリハリがつかなくて読みにくいという問題があります)
BTS自体は使っている(Trac)ので、連携設定をいじってみたいと思います。


修正しない点があれば、それも書く

最近では、いつか直すべきことがあれば、たとえ修正していなくてもそれを書くようにしています。

【不具合修正:XX機能】
・(中略)
・XYクラスの構造は、今回の変更により本来処理をしてはいけない箇所で処理をしている状態になっている。しかし、修正の影響が大きいこと、今後大幅な仕様変更が予定されていることから今回の修正は見送る。


ソースコードを修正する際に困るのが「これはいじっていいのか?」という点です。
ソースを読んでも、以下の三つの区別がつかないことが多いからです。

  • 一見すると問題のあるソースでも、何か意図があってそうしている(バグ回避、など*1
  • 本来は修正すべきだったが、何らかの理由で見送っていた(本リリース直前だった、など)
  • 意図せずそうなっているだけ


1番目の箇所を修正してしまうと、デグレになってしまいます。
なので、ソースコードの修正はいつもびくびくしながらやっています。
でも、そういうときにコミットコメントで「あえて修正しなかった。その理由は〜」と明記されていると、安心して作業ができます。

*1:この理由なら、そもそもソースのコメントに書いておくようにしていますが・・・