CI部の古川(智)です。
本ブログは、読んだ本の感想をまとめている読書感想文シリーズとなっています。
今回も、コード初心者の方向けに、同じくコード初心者の私が『リーダブルコード』を読んで「なるほどなぁ」と思った箇所を紹介していきます。
またコード玄人の方で、この部分解釈違う気がするよ!等、気が付いた方いれば教えていただけると嬉しいです。
(コード例のみ本書から引用しています。)
はじめに
本の内容を全て紹介するのではなく、私が「なるほどなぁ」と思った箇所をピックアップしてお伝えしています。
本の内容をかなり簡潔に記述しているため、興味を持った方は実際に読んでください!
今回のなるほどポイント
前編のおさらいになりますが、リーダブルコードの一貫している主張は「優れたコード=読みやすいコード」です。
それでは今回のなるほどポイントを紹介していきます。
コードの見た目に一貫性を持たせる
コードを書き始めたばかりのころ「空白・空行・改行って一体どこに入れればいいの?」と悩んだ経験ありませんか??
私の場合「あの人はここに空行を入れているが、この人は入れていない…」という場面がよくあり、何を軸にして考えれば良いか分からず困っていたことがあります。
これに関して、リーダブルコードを読んで思ったことは以下です。
空白・空行・改行はコードの見た目を統一するために使用するもの
つまり、空白・空行・改行は読みやすいコードを書くためならばどこで使用してもOKってことなんだな~と思いました。(チームや組織で規則が決められている場合は別ですが!)
また、本書では似ているコードは似ているように見せよう!とも言われています。
例えば以下のコード↓↓↓
Public class PerformanceTester{ public static final TcpConnectSimulator wifi = new TcpConnectionSimulator( 500, /* Kbps */ 80, /* millisecs latency */ 200, /* jitter */ 1 /* packet loss % */) ; public static final TcpConnectSimulator t3_fiber = new TcpConnectionSimulator( 45000, /* Kbps */ 10, /* millisecs latency */ 0, /* jitter */ 0 /* packet loss % */) ; public static final TcpConnectSimulator cell = new TcpConnectionSimulator( 100, /* Kbps */ 400, /* millisecs latency */ 250, /* jitter */ 5 /* packet loss % */) ; }
(『リーダブルコード』, p44)
2つ目の「t3_fiber」のみ書き方が違うため、そこに目が行ってしまいます。
このコードを読みやすくしていきます。
Public class PerformanceTester{ public static final TcpConnectSimulator wifi = new TcpConnectionSimulator( 500, /* Kbps */ 80, /* millisecs latency */ 200, /* jitter */ 1 /* packet loss % */) ; public static final TcpConnectSimulator t3_fiber = new TcpConnectionSimulator( 45000, /* Kbps */ 10, /* millisecs latency */ 0, /* jitter */ 0 /* packet loss % */) ; public static final TcpConnectSimulator cell = new TcpConnectionSimulator( 100, /* Kbps */ 400, /* millisecs latency */ 250, /* jitter */ 5 /* packet loss % */) ; }
(『リーダブルコード』, p45)
似ているコードは似ているように書く、つまりコードの見た目に一貫性をもたせることで、全体像がつかみやすくなった気がしませんか?
読んでいて「ん?」と引っかかることなく、内容がスルッと頭に入ってきます。
空行と空白の入れ方に気を付けただけで、読みやすさにこれだけの違いが出るのはとても面白いです。
空白・空行・改行をなんとなく入れるのではなく、「一貫性を持たせよう!似せて書こう!」を意識しながら入れようと思いました!
価値のないコメントを書かない
本書に載っていた衝撃の式がこちらです。
優れたコード > ひどいコード+優れたコメント
(『リーダブルコード』, p60)
これを見たときに私は大反省しました。まさに「ひどいコード」を「コメント(※「優れた」とは言えないです)」で補っていたからです。
可読性がすこぶる悪いコードを書いてしまったが、もうここまで書いてしまったから書き直せない…。
でもこのままではレビュアーを困らせてしまう…。
と思って、超丁寧なコメントでひどいコードを補っていませんか???
例えばこんなコメントがあるとします。
// Reply に対してrequest で記述した制限を課す。 // 例えば、返ってくる項目数や合計バイト数など。 void CleanReply(Request request, Reply reply) ;
(『リーダブルコード』, p59)
このコメントは、関数名にある「Clean」を分かりやすく説明しているにすぎません。そんなコメント書くなら
関数名に使用している「Clean」を変えたほうが良くないですか?
ということです。
// ‘reply’ を‘request’ にある項目数やバイト数の制限に合わせる。 void EnforceLimitsFromRequest(Request request, Reply reply) ;
(『リーダブルコード』, p59)
「Enforce Limits(制限を課す)」という単語を使用することで、コメントが無くても関数の意味が分かるようになります。
つまり、コメントで補うな!コードを良くしろ!というのが結論になります。
頑張ります…。
コメントに実例を入れる
上で書いた通り、コメントに力を入れるよりコードを良くすることに時間をかけようという大前提はありつつ、コメントで説明しないといけないこともあります。
実際に自分がコードを読む側になったときも、コメントに助けられることって多いですよね。複雑な処理を行うコードの場合はなおさらです。
コメントもコード同様に分かりやすくかつ正確に書かねばならないと分かりつつも、「どうやってコメントを書けば分かりやすくなるのだろうか、言葉で伝えるって難しい!」と思っていました。
それに関してリーダブルコード内で様々なヒントが書かれており、その中でも一番「これは!」と思ったのが以下です。
コメントに実例を入れる!!
例えば以下のようなコードがあります。
// ‘src’ の先頭や末尾にある‘char’ を除去する String Strip (String src, String chars) ;
(『リーダブルコード』, p74)
サラッと読んで分かった気になってしまいますが、このコメントでは以下のような疑問に答えられません。
- charsは文字列?順序のない文字?
- srcの末尾に複数のcharsがあった場合は?
上のような質問に適切に回答できるコメントが以下になります。
// ‘src’ の先頭や末尾にある‘chars’ を除去する // 実例:String Strip ( “abba/a/ba” , ”ab” ) は“/a/” を返す String Strip (String src, String chars) ;
(『リーダブルコード』, p75)
このコメントを見ると、
- charsは順序のない文字の集合
- srcの先頭や末尾に複数のcharsがあった場合、全て除去する
ということが分かります。
このように、実例を入れると処理内容がコメントを見るだけで分かります!
実例を入れる際の注意事項として、処理結果の全パターンを網羅できている実例でないと意味がないという点があります。
完璧な実例を考えるために時間をかける必要はありそうですが、言葉でツラツラと説明するより良いですよね。
おわりに
4500字も書いていました。
前編に引き続き、中編も書きました。後編もたぶん書きます。
前編↓↓↓
blog.serverworks.co.jp
古川智絵 (執筆記事の一覧)
2020年新卒入社 技術課(SRE1課)に所属 好きな食べ物はみそ汁