リーダブルコード その1

メイン記事

こんばんは!

今回より数回に渡って本の内容をまとめていきたいと思います。

タイトルにもありますが、読む本は「リーダブルコード」という本です。(詳細は下記リンク)

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

1回目なのでなぜこの本を読むのかを少し説明しますと、ぶっちゃけ先輩におすすめされたからです。笑

なので自分でこの本にたどり着いたわけではないんですが、概要を読んでみると確かに自分に必要な力だと思いました。

この本には「読みやすいコード」とは何か。という観点から様々な項目で事例を紹介しています。

まだ読んでないので推測ですが、変数やブランチの命名から、ソースコードまで色々なノウハウが詰まっているんだと思います。

読みやすいというのは、チームの仲間にはもちろんですが、例えばバグを直す時などの未来の自分へもメリットがあります。

ということでまだまだひよっこな私はこの本で「読みさすさ」を学んでいきたいと思います。

1章 理解しやすいコード

冒頭から読みやすいと連呼していましたが、読みやすいとはつまりどういうことなのでしょうか。

この本では「読みやすい」=「理解しやすい」と定義しています。

ソースコードって書く人によって、色々な書き方があります。

そして目的の機能が果たせれば、’間違い’ではないんですよね。

でもそれにあえて良し悪しをつけるなら、その基準は読み手が理解するのにかかる時間です。

なのでコードは読み手が理解しやすく書くこと、そしてそれを意識しておくことが自身の成長にもつながります。

2章 名前に情報を詰め込む

はい、来ましたね、命名方法です。

私は入社して早々、ブランチ名に日本語を入れようとして止められましたが、名前というのは短いコメントのような物です。

なのでいろいろな解釈ができる名前(例:post 何を送るのかわからない)よりも明確な単語(例:SendMail)の方が好ましいです。

また、必要な情報は多少長くなってもスネークケースを使用して表示すべきです。(例:暗号化すべきパスワードいれる変数はpasswordよりもplaintext_password)

ここで名前が長くなることについて、打ちにくいからというのは理由になりません。

なぜなら多くのエディターには補完機能がついているためです。

ただし、あまりにも長くて見づらくなる場合は改めましょう。

また、先ほど出たスネークケースのように、フォーマットによって独自のルールを決めるのも良いです。(クラス名はCamelCase,変数名はSnake_Case,定数はCONSTANT_NAME)

事なのは初見の人でも理解できるかという視点です。

ということで今日は2章まで進めました。

全部で15章まで、頑張っていきましょう!!

2021.2.4 ガオ

コメント

タイトルとURLをコピーしました