読者です 読者をやめる 読者になる 読者になる

1月 リーダブルコード

2017年は 『1か月に1冊以上技術書を読んでブログを書く』 を目標にしました。

理由は、文章力と技術力がひよっこだからです…>< 稚拙な文章ですが頑張りたい…! 1月はリーダブルコードを読みました。

概要

http://amzn.asia/ehIqGwI

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

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

「美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。そういうコードは使うのが楽しいし、自分のコードもそうあるべきだと思わせてくれる。本書の目的は、君のコードを良くすることだ」(本書「はじめに」より)

エンジニアならみんな持ってるリーダブルコード。 美しく、他人にわかりやすいコードを書くための考え方やテクニックがたくさん載っています。 文量もそこまで多くなく、230ページほどで少しづつ読んでも1週間かからないぐらいで読めます。参考までに私は2日で読み終えれました。

学んだことメモ

  • 良いコードの定義: 他人が理解するのにかかる時間が短い
  • 良い命名は変数の目的や値を表す(2乗の合計を表す変数: sum_squares)
  • メソッド名や変数だけを見て理解できるかを心がける
  • ミリ秒を返す変数は『ms』をつける
  • 複数行にわたる変数への代入などで、縦の列を揃えるために空白をうまく使おう
    • 空白めんどくさいと思っている人がいるが、実際のそこまで手間ではないし縦を揃えることでタイプミスを見つけやすくなる
  • プログラミングの時間はほとんどがコードを読む時間
  • いい感じに決めた定数には、いい感じに決めたということをコメントとして書いておく
  • コメントを書く作業は3つに分けられる
    • 頭の中でかけるコメントをとにかく書き出す
    • コメントを読んで改善が必要なものを見つける
    • コメントを改善する
  • コードを読んだ人が『えっ』と思ってしまうところにコメントを入れる
  • コメントに代名詞を使わない(その、あの、このとか)
  • if文で、単純な条件を上に書く
  • ライブラリが何を提供してくれるかを知ることは大事
  • たまに標準ライブラリのすべての関数・モジュール・型の名前を15分かけて読んでみるといい

感想

一貫して、『読みやすいコード』を書くためにどのようにしたらよいかという強い気持ちが感じられました。

初めに、命名のコツやコメントの書き方などのすぐ実践できそうな表面上のtipsを多く紹介していて、 後半は、ロジックやコードの再構成の方法などの内容になっていて一気に読み進められました。

章の初めに、その章で言いたいことを絵で書いてあってそれがすごい面白くてわかりやすい。

文量も多くなく読みやすい、でもすごい学ぶことが多い。さすが名著だなあという感じです。

考えてみれば、プログラミングの時間のほとんどはコードを読む時間なのだッ! (本書 p.43 より)

文章中でこの言葉がすごい心に残ってます。 確かに!と思うと同時に読みやすいコードを書く大切さを改めて感じさせられます。

これからこの本で学んだことを生かして、思い出してコードを書こうと思います。というか書きます。

でもまだ内容全部を覚えてないので、身につくまで定期的に読みなおさないとなあ。毎朝15分定期的に読みなおすことにしよう。