分かりやすいコードの書き方
第１話：分かりやすいコードとは
（最終更新日：2025.3.30）
（絵が小さい場合はスマホを横に）
分かりやすいコードとは？
「分かりやすいコードを書くことは大切」とよく言われるが、実際に「分かりやすいコード」とは何かを説明できる人は少ないかもしれない。
本シリーズでは「誰が書いても同じようなコードになり」「副作用が少なく」「変更・拡張しやすく」「読みやすいコード」 を目指し、
具体的な技術や設計方法を解説する。第1回のテーマは「分かりやすいコードとは何か」を取り上げる。
１.なぜ「分かりやすいコード」が重要なのか
なぜ「分かりやすいコード」が重要なのか。
それは、ソフトウェア開発では、コードを書く時間よりも 読む時間のほうが圧倒的に長いという事実にある。
ある調査では、開発者の 約70%の時間が「既存のコードを読むこと」に費やされるというデータがある。
つまり、第三者にとって分かりやすいコードを書くことは、開発時間を大幅に短縮することにつながる。
では、分かりにくいコード（悪い例）と分かりやすいコード（良い例）を見てみよう。下記は、C言語での例になる。
下記は悪い例になる。その理由は、関数名が意味不明で何の処理をしているか分からない。
引数の意味も不明で、何を表しているのかが分からない。
中身の計算も何のための計算か全く分からない、ということである。
分かりにくいコード
次は良い例である。 まず、関数名が明確で（printTotalAmount：合計金額を出力）、 引数の意味も明確（baseAmount：基本料金、additionalAmount：追加料金、taxRate：税率）で、 計算処理の意図も明確（（基本料金+追加料金）x 税率）である。 おそらく、「食事代金 + サービス料金」を算出し、消費税込で幾らになるかを計算しているのだろう。
分かりやすいコード
このように、コードの「分かりやすさ」は、開発者がコードを読む時間や手間を大幅に削減する。 これは、ミスリードによる不具合を防ぎ、チーム開発をスムーズにする効果がある。 上記２つの例を比べるだけでも、その大切さが伝わっただろう。
２.「書きやすいコード」vs「読みやすいコード」
２.１ 「書きやすいコード」とは
書きやすいコードとは、人によって条件は異なるかもしれないが、
例えば「短く書けて」「素早く実装できて」「自分ルールで実装」するようなコードのことを指す。
自分の頭の中では、どんな処理をするのか分かっていて、短くエレガントに書いたつもりかも知れないが、
第三者が見ると、関数や引数、処理の意味が全く伝わってこないコードになりがちである。
以下が、そのような例になる。ラムダ式を使って、短くしているがパッと見分かりにくい。
何より、C++のauto（型推論）を使っているのもよろしくない。
悪い例
２.２ 「読みやすいコード」とは
読みやすいコードとは、チームの誰が読んでも理解しやすく、
関数や処理の意図が明確で、結果、メンテナンスしやすいコードのことだ。
上記を読みやすいコードに変えると以下のようになる。
コードは長くなったが、意味は明確で、第三者がパッと見で分かる。
意味が曖昧になるくらいであれば、長くなっても正確に意図が伝わる方が良い。
良い例
３.良いコードの4つの条件
ここでは「分かりやすいコード」を構成する4つの重要な要素を紹介する。
３.１ 統一性（Consistency）
「誰が書いても同じようなコードになる」という仕組みが重要である。
コーディング規約やLinter、Formatterを用いて、命名規則、インデント、コメントのルールを統一する。
Gitにおけるプルリクエストを必須にして、ルールから逸脱したコードを修正するという方法もある。
統一性とは、例えば関数名は、（先頭だけ小文字の）ローワーキャメルケース（lowerCamelCase）で統一するなどである。
３.２ 可読性（Readability）
可読性とは、一目でコードの意図が伝わることである。
適切な命名、適切なコメント（通常のルールでは分からない場合の説明など）、長すぎる関数を分割するなどである。
３.３ 拡張性（Extensibility）
拡張性とは、機能追加しやすいコードのことである。
新しい要件、機能を追加するときに、その影響を最小限に抑える工夫であったり、
目的に特化しすぎない汎用的な関数にするなどである。
ただ、汎用性に関しては塩梅が難しく、意味が伝わりにくくなるくらいなら、必要に応じて汎用的に書き直すということでも有りだ。
なので、ここは汎用性よりは意図、目的が分かる関数を最初に書く方が良いと思う。
３.４ 変更容易性（Maintainability）
文字通り、変更しやすいコードのことを指す。具体的には、関数や変数などの影響範囲を小さくすることが大事だ。
例としては、ハードコーディングしないということが挙げられる。設定値を定義しておけば、設定値が変わっても関数自体を変更する必要がなくなる。
変更容易性の悪い例と良い例
４.コードの良し悪しを判断する基準
コードを見直す際に、以下の 4つの質問 を自問自答すると、より分かりやすいコードになる。
- 4つの質問
- コードを読んだとき、一目で意図が伝わるか？
- 変数名や関数名は適切か？
- 変更や機能追加が簡単にできるか？
- 読んだ人が「？」と思わないか？
５.まとめ
今回「分かりやすいコード」が、チーム開発の生産性と品質に大きく寄与することを説明した。 そして「分かりやすいコード」とは、誰が読んでも意図がすぐに伝わり、保守や拡張がしやすいコードを意味する。 特に命名の明確さ、統一されたスタイル、関数の責務の明瞭さが重要になる。書きやすさよりも読みやすさを重視し、 将来の自分や他人が見ても迷わない構造を心がけることが、良いコードを書く第一歩になる。 今回のポイントを参考に、自分のコードをリーダブルなものに改善していこう。
▼参考図書、サイト
「リーダブルコード」 Dustin Boswell、Trevor Foucher 著、角 征典 訳 オライリー