プログラミングの初心者が書き方の基礎を学ぶのに最適な本「リーダブルコード」

最終更新日

こんにちは、DUです。

およそ4年ほどプロのエンジニアとして開発の現場にいる筆者が、4年経った今でもコードを書く上で、最低限意識していることを振り返ったところ、新人の頃に購入した「リーダブルコード」にそのまま同じような内容が書いてありました。(ずっと意識していたんですね;;)

色々なエンジニアが一度は目を通しているであろう本ですので、プログラミング初学者の方、就職してチーム開発を進める予定のある方は、ぜひ一度手にとってみてください。

「リーダブルコード」は日本語に翻訳された本の初版が2012年に出版され、長く読まれている本です。

似たような内容で「Clean Code」という本があります。こちらは私がアメリカでインターンシップをしていたときの上司に勧められたもので、最近日本語版も出版されました。どちらかお好みで選ぶと良いかもしれません。

「リーダブルコード」の方が薄く、読みやすいので個人的にはこちらがオススメです!

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

はじめに

正直言ってしまうと、「リーダブルコード」に書いてあることはものすごく基本的なことばかりです。

逆にいうと、3年目以上のエンジニアで未だにこの辺りの素養がないエンジニアは、正直ヤバいです。少し意識しながらコードを書いていくと、自然と身につくことですので、なるべく早めに基礎的な内容を頭に入れましょう。

そして、もう1つの注意点はこの本に書かれていることが「完全無欠なルール」ではないということです。

コードスタイル・書き方は最終的には好みの問題で、読みやすさ・フォーマットの綺麗さ、これらも全て主観的なものです。「リーダブルコード」の良いところは、この書き方が正解だという主張ではなく、気を配るべきポイントを挙げている点です。

それらの内容をチーム内で議論したり、使っているプログラミング言語のコミュニティと照らし合わせることで独自のコーディングスタイルが出来上がっていきます。

「リーダブルコード」の例がこうなっていたから、この通りにすべきだ!という主張はしないように気をつけましょう。あくまで参考例程度の認識でいたほうが良いと思います。

最低限コードを書く際に気を配ること

それでは、実際に「リーダブルコード」でも触れられている、私が今でも気をつけている点を紹介します。

先に結論から言ってしまうと、以下の4つの点です。

ポイント

1. 名前の付け方
2. フォーマット
3. コメントの有無
4. 簡潔さと冗長さのバランス

1. 名前の付け方

まずは、名前の付け方です。自分で開発している分にはどんな名前をつけたとしても、振る舞いはすぐに認識できるでしょう。しかし、共有資産のコードは名前1つつけるのも、気を配る必要があります。

本書では、この部分を

名前に情報を詰め込む

と表現しています。

より具体的には、

1. 曖昧さを排除
2. 長さは気にせず、より具体的に(スコープによる)
3. 接頭・接尾辞に付加情報

といった点です。

曖昧さ

曖昧さの代表例は「make」でしょう。

「make」は「作る」という意味ですが、これだけだと新規に作るのか追加するのか、組み合わせるのか全くつかめません。「create」「add」「compose」など、もう一歩踏み込んだ単語を使うことでよりイメージがクリアになります。

具体的

より小さいスコープのみで有効な変数であれば、短い名前でも問題ないと思います。たとえば、ループ内のindex名などはよく「i」が使われますね。

しかし、グローバルで使われるクラス内のpublicメソッド名が端的すぎると、よほどクラス名が具体的でわかりやすくなければ、そのメソッドが何をしているのか判断することができません。

「リーダブルコード」の例を引用すると、TCP/IPポートをサーバがリッスンできるかどうかを確認するメソッド名が「ServerCanStart()」と付いていると、そのメソッドが実際に中で何をチェックしているのかわかりません。

その場合、「CanListenOnPort()」とすることで、ポードがリッスンできる状態なのか確認していることがより明確になります。

具体的(説明的)な名前になればなるほど、名前は長くなっていきます。長くて書くのが面倒だと感じるかもしれませんが、現代ではほとんどのエディタが「補完機能」を備えてるので、全て書くまでもなく補完でコーディングできます。ほとんど長い名前による苦労はありません。読み返す時のために、なるべくわかりやすい命名を心がけた方がメリットを享受できます。

接頭辞・接尾辞

プログラミング言語は基本的に型というものが存在します。それが静的であろうと動的であろうと、型は存在します。

その中で、「isAliveProcess」や「canListenPort」など「is」や「can」を接頭辞に含めた変数名をつけることで、その値ががboolean型であることが予測できます。

また時間を表す変数では、その値が「秒」「分」「時間」「ミリ秒」なのか「time」という名前からだけでは予測することができません。そういった場合は「~Mins」「~Secs」など単位を表す接頭辞をつけることで、より明確なコードとなります。

2. フォーマット

次に、フォーマットです。これは読み返す時のために、綺麗に整えていた方が良いです。

ほとんどのプログラミング言語にはコーディングスタイル規約があるでしょう。そちらを参考にすることが一番です。

おおまかに、

代表例

1. インデント(スペース or タブやインデント幅)
2. 制御構文や関数定義時のカッコの位置
3. 1行あたりの最大文字数
4. 変数定義時の「=」の揃え方
etc.

挙げるとキリがありません。コミュニティから提供されているガイドラインを遵守しつつ、残り部分は所属する組織内で好みの押し付け合いが発生するポイントです。

私はこの部分をコードレビューで指摘されるのが、一番嫌いです。完全に主観的な好みの議論に終始するからです。事前にしっかりとルールを設定して、自動的に決められたフォーマットになるようにLinterなどを仕込んでいる組織が健全です。

3. コメントの有無

持論は、「コメントが少ないに越したことはない」です。

なぜなら、先ほど述べた「名前の付け方」とコード設計でいくらでも読みやすさを追求することができるからです。

しかし、そこは臨機応変に対応しましょう。

その時点ではコードが十分読みやすく、メンバー全員が挙動を把握していたとしても、時間とともにコメントの偉大さに気づかされる場面はあります。

ソフトウェアの開発は時間とともに、管理が難しくなっていくことは歴史的に明らかです。それを防ぐために設計から見直したり、コードをリファクタリングしたり様々な対応を試みても、完全な解決策ではありません。

特に年季の入ったコードほど読みにくいのですが、当時のコメントが役に立つことも多々ありました。自分のコードが完璧であることはありえないので、複雑な処理であればコメントを書いてもいいかもしれません。

基本的にはコメントを書かなくてもいいようなコードを心がけ、時と場合によってはコメントを足していく

というスタンスに最近は落ち着いています。

4. 簡潔さと冗長さのバランス

最後は、簡潔さと冗長さのバランスです。

基本的なスタンスは、なるべくシンプルに書くことです。

ひたすら「if ~ else」がネストされているコードを平気で書くエンジニアがいますが、逆にその複雑さで全てのケースを網羅できていることが凄いです。私には、その分岐を瞬時に処理できる能力はありません。

完全な皮肉を述べてしまいましたが、その当事者にとっては良くても、あとから読み返す人にとっては地獄です。また、バグの温床地帯でもあります。

シンプルに書く」というのは簡単なようで、ものすごく頭を使う作業です。そのシンプルさを実現するために、排他的に物事を捉えて、データ構造なども上手く使いながらコーディングする必要があるからです。

この点は、経験を積み重ねていくことでしか伸ばすことができないかもしれません。特にエントリーレベルとシニアエンジニアの違いが現れるポイントですね。

ただし、気をつけなければいけないのは「Simple is the best」ではないことです。

これは非常に重要な点で、「リーダブルコード」でも取り上げられています。「シンプルさ」と「読みやすさ」を履き違えないように、ということですね。

複数条件の制御構文を三項演算子を連続して記述したり、必要ない箇所でビット演算をしようしたり、見た目は小さくシンプルでも、読み解くのに時間がかかっては意味がないのです。

シンプルにというのは、クラスやメソッドの設計から生まれるものなので、長いものを短くすることではありません。

おわりに

いかがでしたでしょうか?

これらのポイントを挙げた後に気づいたことは、理想の状態は

いかに「必要十分なコード」を書けるか

ということです。足りなくても、必要以上に冗長であることもなく、いかに良いバランスでコードを書けるか。

私自身も、これを意識しつつも理想的なコードを書けている自信はありません。毎回レビューを受けたり、人のコードを読むことで新しい発見をしつつ成長している段階です。

みなさんもぜひ、一度この本に目を通してみてはいかがでしょうか。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック
Clean Code アジャイルソフトウェア達人の技 (アスキードワンゴ)