こんばんは!
今回より数回に渡って本の内容をまとめていきたいと思います。
タイトルにもありますが、読む本は「リーダブルコード」という本です。(詳細は下記リンク)
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
1回目なのでなぜこの本を読むのかを少し説明しますと、ぶっちゃけ先輩におすすめされたからです。笑
なので自分でこの本にたどり着いたわけではないんですが、概要を読んでみると確かに自分に必要な力だと思いました。
この本には「読みやすいコード」とは何か。という観点から様々な項目で事例を紹介しています。
まだ読んでないので推測ですが、変数やブランチの命名から、ソースコードまで色々なノウハウが詰まっているんだと思います。
読みやすいというのは、チームの仲間にはもちろんですが、例えばバグを直す時などの未来の自分へもメリットがあります。
ということでまだまだひよっこな私はこの本で「読みさすさ」を学んでいきたいと思います。
1章 理解しやすいコード
冒頭から読みやすいと連呼していましたが、読みやすいとはつまりどういうことなのでしょうか。
この本では「読みやすい」=「理解しやすい」と定義しています。
ソースコードって書く人によって、色々な書き方があります。
そして目的の機能が果たせれば、’間違い’ではないんですよね。
でもそれにあえて良し悪しをつけるなら、その基準は読み手が理解するのにかかる時間です。
なのでコードは読み手が理解しやすく書くこと、そしてそれを意識しておくことが自身の成長にもつながります。
2章 名前に情報を詰め込む
はい、来ましたね、命名方法です。
私は入社して早々、ブランチ名に日本語を入れようとして止められましたが、名前というのは短いコメントのような物です。
なのでいろいろな解釈ができる名前(例:post 何を送るのかわからない)よりも明確な単語(例:SendMail)の方が好ましいです。
また、必要な情報は多少長くなってもスネークケースを使用して表示すべきです。(例:暗号化すべきパスワードいれる変数はpasswordよりもplaintext_password)
ここで名前が長くなることについて、打ちにくいからというのは理由になりません。
なぜなら多くのエディターには補完機能がついているためです。
ただし、あまりにも長くて見づらくなる場合は改めましょう。
また、先ほど出たスネークケースのように、フォーマットによって独自のルールを決めるのも良いです。(クラス名はCamelCase,変数名はSnake_Case,定数はCONSTANT_NAME)
大事なのは初見の人でも理解できるかという視点です。
ということで今日は2章まで進めました。
全部で15章まで、頑張っていきましょう!!
2021.2.4 ガオ
コメント