レガシーコードの特徴を具体的な4つの例を示して問題点をまとめます

新卒で入社した企業では20年物のソースコードが現役で動いていたりしました。しかも協力会社に丸投げした部分やインドにオフショアした部分などが入り混じってカオスとなっていました。エンジニアも玉石混在で、カオスに練度の低いエンジニアが保守拡張したりしてカオスがさらにカオスに。そんなソースコードには発狂しそうになるレガシーコード（一部ではウンコードと呼ぶ人もいる）が豊富に眠っていました。今回はレガシーコードの反面教師としてその具体例を挙げてみます。

レガシーコードの具体例

意図が分からない

if ( path != null )
{
    str = Path.Combine(path, fileName);
}
else
{
    str = path + fileName;
}

たぶんpathがnullでPath.Combineでクラッシュする不具合があったんでしょうね。それを修正した結果が上のコードになったのでしょう。pathがnullのときクラッシュすることはこれで回避できた（できてるこれ？）かもしれませんが、nullのときstrは本当に問題ないんですかね…。この不具合修正で新たな不具合を作っていそうです。

無駄なファイル生成

File.Copy("A.txt", "./Files/B.txt");
...
File.Delete("./Files/B.txt");
File.Copy("C.txt", "./Files/B.txt");

A.txtをB.txtにコピーしていたのですが、A.txtもB.txtも一切操作せずにB.txtを削除する処理が実行されていました。何のためにコピーしたのか意図が分かりません。意図が分からないので削除して良いのか判断するのが難しいです。

謎のコメントと気遣い

if(...)
{
  // ここが実行されることはないが、一応残しておく
  ...
}

消してください。古いソースコードはGitやSVNなどのバージョンコントロールツールがない時代から作られているので、コメントアウトでソースコードの変化を記述して残そうとしている場合があります。Visual Studioを画面一杯に表示して縦に100行くらいは表示できるのに、コメントアウトでプログラムが数行しか表示できないなんてケースも遭遇したことがあります。

コメントアウト失敗

if(False)
  // NotImportantMethod();
VeryImportantMethod();

if文の中身をコメントアウトしたつもりが、{}を省略していたため次のステップが実行されなくなってしまった例です。不具合を追っていたらここにたどり着きました。このような不具合を引き起こす可能性があるので、Microsoftのコーディング規約では{}の省略を禁止しています。