汚いソースコードの分類と対策

「綺麗なソースコードはどれも似ているが、汚いソースコードは千差万別だ」by トルストイ
  • 「良いソースコードは短いけど理解に時間がかかるソースコードではなくて、長くても理解するまでにかかる時間が短いソースコード」というのが私の哲学です。
  • たまには逆向きに汚いコードの特徴と対策を整理してみました。

関数名や変数名が不適切なケース

  • 公式のコード規約に沿うことである程度は解消できる

処理全体概要が見えないケース

コードを読んでも結局何をしたいのかの全体像が見えない。これには複数の可能性が存在しそれぞれ有効な対処方法が異なる。

レイヤーの異なる処理が混在している場合

  • モジュール化を行いファイルを分割する。1ファイル中にレイヤーの異なる処理が混在しないようにする
  • 処理毎にファイルが別れていてかつ個別のファイル内部の処理は非常に簡単を目指すべき。
  • これは単一責任の原則によくマッチしている。

処理対象のデータの具体例が見えない場合

  • コードだけから中身を推測するのは無理
  • コメントに大まかな処理の流れや入出力結果の例を記載する

スパゲッティコード

その場しのぎで継ぎ足し処理が原因の場合

  • 後付で処理を付け足していくと、ifやelseがあちこちの処理に散在するスパゲッティコードになる。
  • 対策としては実装の最初の段階から各処理のスコープを意識して設計する。
  • 修正する場合はリファクタリングが必要となる(最悪の場合はソースコードの書き直しとなる)。