本書は、読みやすいコード=理解しやすいコードという考えで書かれています。そのため、理解しやすいコードを書く方法について4部にわたり取り上げています。
本の紹介
読みやすいコード=理解しやすいコードという観点で本書は書かれています。誰にとって理解しやすいコードなのか、他人や数か月後の自分にとって理解しやすいコードにしようというスタンスです。
本書は、翻訳本特有の読みにくさがあります。加えて口語体で書かれています。
学んだこと
表面上の改善
1部では、変数名の付け方、コードのスタイル(インデントなど)、コメントについて書かれています。プログラミング初学者の方にも分かる話題です。
変数名の付け方は、日本人なら特に頭を悩ますところだと思います。英語のコードの中にローマ字でnamaeやseibetuなどと変数名を付けてしまうと格好悪くなってしまいます。そのため、英単語で名前を付けたいところですが、その変数に合う英単語を見つけるのに苦労します。適当にx、y、numなどと付けてしまいがちです。それでも構わない場合もありますが、重要な場面では変数名は吟味したいところです。名前には意味が含まれるので、誤解のないような名前付けが大事です。
表面上の改善は、リスクや労力をかけずにできるものです。
ループとロジックの単純化
制御の流れが分かりやすいと理解のしやすさに繋がるというお話です。例えば、if/else文の並び順や条件式を肯定・否定のどちらで書くのかといったことです。長い条件式を変数に代入して、条件式を短くすることは、新たな発見でした。また、ド・モルガンの法則を使い、否定を含む論理式の書き換えは参考になりました。
コードの再構成
どこでも使える使い勝手の良い汎用コードを作ると良いということです。プログラマの方は、各々独自の汎用コードをまとめたライブラリのようなものを持っているのか聞いてみたいです。
元も子もない話かもしれませんが、ライブラリで可能なことはライブラリで済ますのが良いそうです。プログラマなのに自分でコードを新たに書くのではなく、ライブラリで済むものはライブラリで済ませると良いということです。ライブラリはデバッグやテストなどが済んだ状態のコードで、それを使わない手はないです。ライブラリを使うと時間とコードの節約になります。
効率的かつ安全にコードを書くには、ライブラリの力を借りるのは確かに良いことだと思いました。今後は、ライブラリにも注目したいです。自前で何でも書きたいという気持ちは分からなくもないですが、便利に使えるものは使うという心持ちもプログラマには必要なものだと感じました。
感想
複数人で開発するようになったときに、読むと良い本だと思います。複数人で開発する際のマナー的なことが書かれているのだと思います。本書の後半部分で理解しきれていないところがあるので、もう一度読もうと思います。
全体的にためになる内容でした。コードを書くときは、本書を参考に書きたいです。また、コードを書く上で他にも参考になるようなものがないか探したいです。
参考書&マンガのまとめ記事なら... » 参考書とマンガの読書記録
