スクラッチからソースを書くような開発をするのは幸せなことです。
ですが、ほとんどは他人が作ったレガシーコードをだましだまし 使う場合が多いです。
そんな仕事の中で身につけた私のコーディング手法を まとめたいと思います。
１）バージョン管理システムにソースを突っ込む オリジナルのソースをまずはTortoiseSVNやGitなどのバージョン管理リポジトリに 登録します。
これによって思い切りソースを変更しかつ楽に元に戻せるようになります。
この手順は必須です。
２）インデントがでたらめなソースはソース丸ごとインデントをそろえる。
海外の人が作ったソースなどはインデントがおかしいものが多い気がします。
わたしはvimを愛用しているのでggVG後に=%でファイル単位でインデント整形しています。
３）グローバル変数名、メンバ変数名、重要な関数名などがプロジェクト内で 一意な名称になっていないものは一意な名前に変更する。
grep検索でコール元と宣言部、実体部以外がひっかからなくなるまで続けます。
コメント内に関数名が書いてあるものなど言語道断でもちろん削ります。
この作業はコンパイルを行いながら慎重に実施します。
C++で継承を多用している場合は注意が必要です。
私の場合、メンバ変数はm_、グローバル変数はg_のプレフィックスをつけます。
C++の関数オーバーロードを利用されている場合は、全てgrepしたときに重複しない 異なる関数名をつけ直します。
Set()やGet()などのように関数名が短すぎて実質のgrepが意味をなさない場合も grepで一意になるような関数名に変更します。
インターフェースが多用されるなど、継承が多用されている場合はコンパイルが 通らなくなってしまわないように注意しながら行います。
４）重要な関数の引数のコメントや概要をソースを理解しながら適宜記載していきます。
５）コメントアウトされている部分が異様に多く、また意味不明なコメントやデバッグ出力が大量にある場合は、思い切ってコメントを全て削除してしまいます。
元のコメントが見たくなった時はsvn logして見ればよいのです。
私はvimユーザーなので、C/C++の選択範囲内にあるコメントを削除する 自作vim用ツールを利用しています。
以上です。
あとは地道に理解していくしかありません。
その他のTIPSをいくつか紹介します。
６）assertマクロをちりばめる。
assertが入っていないCのソースは、ブレーキのないF1マシンに乗るようなものだと誰かが言ってました。
単体テストソースを作ることと意味は同じです。
７）一発で全ソースをビルドできる環境を作る。
元の開発者は大量のソースを扱うことに慣れておらず 全てを十分コントロールできていなかったのでしょう。
８）ワーニングレベルは最大に。
ワーニングが山ほどでるソースは間違いなく品質が低いです。
９）モジュールは分割しない。
モジュールを複数のdllやexeに分割した場合のデメリットはデバッグが困難になることです。
経験上メリットを感じたことがありません。
あるのは営業上のメリットだけです。
よほどの理由がないかぎりexeひとつにまとめましょう。
ソースのないDLL内で落ちるとデバッグ地獄に。。
10) 参考書籍
10-1)リファクタリング プログラミングの体質改善テクニック／マーチン・ファウラー
辞書のような本です。
この本によると関数の引数を追加するのも削除するのもリファクタリングだそうです。
10-2) WORKING EFFECTIVELY WITH LEGACY CODE / Michael Featers
日本語訳も出ています。
読み物としても結構面白いです。
うん、そうそうと同意すること受け合いです。
