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