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

  • オライリージャパン
4.31
  • (588)
  • (458)
  • (162)
  • (16)
  • (3)
本棚登録 : 5785
感想 : 454
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・本 (260ページ)
  • / ISBN・EAN: 9784873115658

作品紹介・あらすじ

コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。名前の付け方、コメントの書き方など表面上の改善について。コードを動かすための制御フロー、論理式、変数などループとロジックについて。またコードを再構成するための方法。さらにテストの書き方などについて、楽しいイラストと共に説明しています。

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • なるほど、いい本です!あらゆる普遍的な要素が詰め込まれていて、かつ、実用的です。定期的に読み返したいですね。

  • 読んで良かったと思ったので、久しぶりに技術書を載せておく。

    今まで読んできたオライリー本の中では、日本語訳が読みやすかった。翻訳者のスキルもさることながら、著書の英文もシンプルで洗練されていると思われる。「読みやすいコードにするためには」がテーマなので、非常に説得力があった。

    個人的には、変数名そのもので働きをイメージできるようにする、というのが目からウロコ。いつも、変数にコメントつけて、変数は短くすることだけを心がけていたので。多少長くても、誤解のない変数名を心がけるようにします。

  • そういえば読んだことなかった。いかに鮮やかに一行にまとめられるか努力していた時期もあったが、やはり間違いだったと再認識できた。それからテストのやりすぎ問題にも共感。ほんのちょっと人に親切に書くというポリシーで行くのがいいのかもしれない。
    56冊目読了。

  • プログラミングを始めて半年くらいのド新人。
    rubyしか触ったことがないのでサンプルコードはわからない部分も多かったし、後ろに行くほど難しかった。
    けど、理解できた最初の方だけでも充分に読む価値はあった。

  • (概要)
    可読性の高いコーディング方法について書かれた本。
    可読性は保守性や効率性とも基本的にはトレードオフではないため、可読性の高いコードは”良いコード”と同じ意味を持つ。本書ではその方法を変数名の命名方法からコードの設計方法に至るまで網羅的に書かれている。

    (感想)
    特にデータ分析者にお薦めしたい本。
    理由は、データ分析者はPythonというゆるい言語でjupyter notebookというインタラクティブな実行環境に書き捨てコードを書くだけでもデータ分析できてしまい、それに甘んじてしまう人がいるだろうと思うからである。(もちろんこれ自体は頭を使わずにコードを書けるという意味では良いことであるし、そもそもただの推測なので間違っているかもしれない。)
    しかし、データ分析者も以下の目的を達成するために、良いコードを書かなくてはいけないと思う。
    ・チームメンバーが短時間で自分のコードを理解できる
    ・汎用コードをモジュール化しておき、手間を省く
    ・データセット管理やモデル実験管理を簡単にする
    何事も頭を使うのは骨が折れるが、私も心がけなければならない。

  • 説明変数、要約変数でコードの見通しを良くするのは有益だった。

    今まではわざわざ1行になるようにコーディングしていたがそれは無益なことだった。

    変数名、関数名も後で理解しやすいように注意して命名しなければ。
    変数名に単位を入れるのは良さそう。

    ネストを深くしすぎるのも良くない。
    タスクを切り分け1関数で1つの事にした方が見通しが良くなるしテストも楽になる。

    関数の途中でreturnして早く抜け出すのは良いこと。

    今までやっちゃダメと思ってた事がホントはそんなことなかった。

    最後のケーススタディ直前まではすんなり進めたが、ケーススタディで一気に難易度が上がった。

  • コードを書く人の必読書だと聞き、読んでみた。
    エンジニアリングとは、大きな問題を小さな問題に分割して、それぞれの解決策を組み立てることに他ならない。

    自分天才!と思える短いコードを書くより、少し長くても初見の読み手が早く理解できる読みやすいコード、理解しやすいコードを書くことが大事。


    以下、印象に残った内容

    コードを書く際の基本
    ・他の人が最短時間で理解できるように書く

    名前に情報を詰め込む
    ・GetPageではなくFetchPage、StopではなくResumeやPauseなど、処理がより明確になる単語を使って名前を付ける
    ヒント:シソーラス(類語辞典)を使って単語を調べる

    ・イテレータが複数あるときには、インデックスに明確な名前を付ける
    E.g.: i,j,kではなく、club_i,members_i,users_i

    ・変数名に単位を入れる
    E.g.: start_ms

    ・危険や注意を喚起する情報を変数名に追加する
    E.g.:暗号化前のパスワードならplaintext_password

    ・スコープが小さければ、変数名は短くて良い、スコープが大きければ、名前に十分な情報を詰め込んで明確にする

    誤解されない名前
    ・限界値を含める時はlimitではなくmin,maxを使う
    ・範囲を指定する時はfirst,lastを使う
    ・包含/排他的範囲にはbegin,endを使う(beginは含め、endは含めないが基本)
    ・ブール値の変数名は、頭にis,has,can,shouldなどをつけて分かりやすくする

    美しさ
    ・同じような処理をしているコードは、シルエットも同じようにする
    ・コードの列を整列する
    ・ある場所でA,B,Cの順に並んでいれば、別の場所でもA,B,Cの順にする

    コメントすべきことを知る
    ・自分の考え、質問されそうなこと、処理の全体像、定数の値にまつわる背景などはコメントに記す
    TODO:あとで手をつける
    FIXME:既知の不具合があるコード
    HACK:あまりキレイじゃない解決策
    XXX:危険!大きな問題がある

    制御フローを読みやすくする
    ・If/else条件は、否定形よりも肯定形を使う。単純な条件を先に書く。関心を引く条件や目立つ条件を先に書く

    ・do/whileループを避ける

    ・早めに関数から返して、ネストを削除する

    巨大な式を分割する
    ・式を表す変数、説明変数を使う。式を説明不要でも、式を変数に代入すると便利
    E.g.: username=line.split(':')[0].strip()

    ・ド・モルガンの法則を使い、notを分配して、and/orを反転する

  • 定番だし読まねばと思って4,5年経ってしまったけれど、ようやく読了。
    一度は読んだ方がいい、というのも納得。
    難しいテクニックは書かれていないし、言われてみれば当たり前のようなことばかりだけど、その当たり前が大事だよね…
    「リーダーの作法」のコーディング版みたいな印象を受けました。

  • とても勉強になった。
    変数の付け方の初歩的な話から、コメントの付け方等など模範解答のような決まった正解が無いものについて、概念的な説明ではあるが正解を教えてくれた。

    初めて1年未満の自分としては、ちょっとコードに慣れてきて短く書くことが至上のように考えて、読みやすさを棚に置いていた節があり、この本を読んで反省した。

    兎にも角にも、人に理解されるようなコード、理解しやすいコードを書く事を意識すれば良い。自己満なオナニーコードはダメと言うことが分かった!!

  • 昔、エンジニア時代に読んで大変勉強になった記憶がある。
    約10年を経て読みなおし、改めて良本だと感じた。

    「コードの読みやすさとは、他人が理解するのに必要な時間の短さ」
    うん、共感。

    最近マネージャとして担当したPJにおいて、
    ソースレビュー(プルリクエストの相互レビュー)をチーム内で徹底し、
    プロダクト品質とメンバースキルの底上げを図ろうとした。
    そのためには、レビュワが率直なフィードバックをすることが不可欠だが、
    「自分ではこう書かないな」と思っても、
    「まぁ好みの問題か、一応正しく動くからよいか」となり、
    明らかな欠陥以外は指摘しづらい状況に陥ることに気付いた。

    「良いコードの基準」が人それぞれ異なり、
    客観性がないことが原因のひとつだろう。

    ということで、この本をチーム全員で読んだ。
    ライトな表現で読みやすく、メッセージもシンプルで明確な本のため、
    メンバーの経験値を問わず、全員が理解しやすい内容だと感じた。
    おかげで、チームとしての共通基準らしきものを得られたと感じる。
    今後はレビュワが(妙で無意味な)遠慮をすることなく、
    「〇章にもあったように、ここはこうした方がベター」
    というフィードバックができるようになることで、
    プロダクトの品質維持向上ができるチームになる、はず・・・!

全454件中 1 - 10件を表示

Dustin Boswellの作品

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×