「良い」コードを書くためのコーディングルール

はじめに

この記事は「良いコード／悪いコードで学ぶ設計入門」を読んだうえで比較的簡単で意識しやすいと感じたポイントを自分なりに整理するために書きました。
開発エンジニアをやっていると、非常に読みにくいコードに出会って理解するのに多くの時間を要してしまう経験がある方も少なくないのではないでしょうか？
そんな悲劇を生まないようにこの本を読んで「良い」コードを書くためのコツを身に着けていきましょう！

悪いコードとは

良いコードを書くために、まずはどのようなコードが悪いコードなのか代表的なものを押さえておきます。

意味不明な命名

クラスやメソッド、変数名などに対して以下のような命名をするのは後から見た時に目的や意味が分かりにくくなってしまうため、避けた方が良いです。

• 技術駆動命名
  型名やプログラミング用語といった専門的なワードを使用した命名方法。

// 例）
intValue = 1;

　

• 連番命名
  特に意味を持たない番号付けをして命名する方法。

// 例）
value01 = 1;
value02 = 2;
value03 = 3;

複雑な条件分岐

多重ネスト構造

プログラミングの基本制御としてif文などの条件分岐がありますが、条件分岐が複雑になってきてif文の中にif文、さらにその中にif文...といった形で何重にも判定を入れてしまうような多重ネスト構造になってしまうことがあります。
ネストされている層が深ければ深いほどコードの見通しが悪くなってしまうのでなるべく避けた方が良いです。

// 例）
if (条件1) {
    if (条件2) {
        if (条件3) {
        ...
        }
    }
}

巨大なネスト

ネスト構造の階層が比較的浅いものであっても処理内容が数十～数百行の実装がされているとif文の始まりと終わりの括弧を探すだけでも大変になります。
このような巨大ネスト構造はコードを理解するために時間がかかってしまうだけでなく、仕様変更などで手を加える必要に迫られた際にはロジックを正確に読み解くことが困難になってしまい、十分な理解ができないまま修正を加えるとバグの発生源となってしまうことが多いです。

// 例）
if (条件1) {
    //
    // 数十～数百行の処理
    //
    if (条件2) {
        //
        // 数十～数百行の処理
        //
        if (条件3) {
            //
            // 数十～数百行の処理
            //
        }
        //
        // 数十～数百行の処理
        //
    }
    //
    // 数十～数百行の処理
    //
}

良いコードを書くためには

ここまでで悪いコードの代表的な例を挙げました。（もちろん他にも様々な要因がありますが。。）
ここでは挙げた例に対して、良いコードを書くためにはどのようなことを押さえておくべきかをまとめていきます。

命名規則

プログラミングにおいて適切な命名をすることはコードの可読性を高めるために特に重要な要素となります。
そのコードが"何のために存在しているのか"という目的をベースに命名する目的駆動名前設計という設計手法を用いることで、コードの意図を明確化すると良いです。

キーワード：命名駆動名前設計

目的駆動名前設計におけるポイントを挙げます。

• 可能な限り具体的で意味範囲を狭くした名前にする
• 関数、メソッド名は「動詞＋目的語」の形にする
• そのコードが「何をするのか」を明確に表す名前にする
• プロジェクト全体で命名規則を統一する
• 基本的に長い名前でも省略はしない

条件分岐

条件分岐では多重ネストや巨大なネスト構造にならないように工夫する必要があります。
そこで利用すると良い手段として早期returnがあります。
早期returnは条件を満たしていない場合、ただちにreturnで抜けてしまうという手法です。

キーワード：複雑なネスト構造を回避するためには早期return

保守しやすくするためのコメント

コードの理解をしやすくするうえでコメントも重要なポイントですが、これも扱いを間違えるとかえってわかりにくく、バグの原因ともなりえます。
コメントを付ける際には以下のポイントに注意すると良いです。

• ロジックを変更した場合、必ずコメントも変更すること
  コメントを変更しないと、ロジックとの乖離が進んでしまう。
• ロジックをなぞるだけのコメントはしない
  あまり可読性には貢献せず、メンテナンスのコストが上がってしまう。
• 可読性の悪いロジックを説明するのではなくロジックの可読性を上げる
• ロジックの意図や仕様変更時の注意点をコメントに残す

最後に

この記事では良いコードを書くために比較的意識しやすい部分をピックアップして紹介しました。
まずは、紹介したポイントを押さえておくことが大事だと思います。
今回紹介したこと以外でも様々な要因で保守性が悪くなってしまうので、より具体的に知りたい場合は参考として挙げた書籍などを読んで知見を取り入れていくことをお勧めします。

参考