リーダブルコード の商品レビュー
基礎的なことが書かれているが、読んだことがなかったら読んでみよう。実践できてなかったら、すぐ取り入れよう。ほとんどの人はすでに身についていると思うが復習のために。
Posted by
ほんとこれ!って思った箇所、特に実践したいと思った箇所 ■3章 誤解されない名前 3.6 ブール値の名前 ■5章 コメントすべきことを知る 5.3 読み手の立場になって考える ■6章 コメントは正確で簡潔に 6.8 情報密度の高い言葉を使う ■7章 制御フローを読みやすく...
ほんとこれ!って思った箇所、特に実践したいと思った箇所 ■3章 誤解されない名前 3.6 ブール値の名前 ■5章 コメントすべきことを知る 5.3 読み手の立場になって考える ■6章 コメントは正確で簡潔に 6.8 情報密度の高い言葉を使う ■7章 制御フローを読みやすくする 7.5 関数から早く返す 7.7 早めに返してネストを削除する ■10章 無関係の下位問題を抽出する 10.5 プロジェクトに特化した機能 ■12章 コードに思いを込める 12.3 この手法を大きな問題に適用する ■13章 短いコードを書く 13.3 コードを小さく保つ ■14章 テストと読みやすさ 全部 14章のテスト駆動開発(TDD)はまだやったことないけど、かなり気になる~!1回実際にやってみたい。
Posted by
各章に例が提示され,非常にわかりやすく,楽しく読めました.仕事がたてこみ二週間で読むことは出ませんでしたが,十分一,二週間で読み終えることができます.また,一回だけでなく覚えれるように何度も読む必要があると思います.
Posted by
元Googleのプログラマらによる、他の人から読みやすいコードをかくためのコツに関する本。 大半の部分はどこかで見たような話だがよくまとめられていて、全体としては自分またはチームのコーディングポリシーを決める際の基準などとして役に立つ。 特に、識別子名の決め方は参考になり、ひい...
元Googleのプログラマらによる、他の人から読みやすいコードをかくためのコツに関する本。 大半の部分はどこかで見たような話だがよくまとめられていて、全体としては自分またはチームのコーディングポリシーを決める際の基準などとして役に立つ。 特に、識別子名の決め方は参考になり、ひいてはリファクタリングの参考にもなる。つまり、命名しにくいメソッド、クラスなどは複数の責務を担っているから分離すべき、という内容だ。 具体例も少しはあるが、全体の抽象度としてはJavaスタイルガイドと達人プログラマーの間にいる感じである。
Posted by
変数名・関数名などの名前付けやコメントの書き方など、具体的な例を用いながらより良いコードを書く方法をとてもわかり易く説明している。 新人プログラマーの教育目的に最適。コードレビューを担当するような中堅プログラマーも必読。
Posted by
リーダブルコードを読んでみて vol1 - まほろば技術パーク http://komeshogun.hatenablog.jp/entry/20141106/1415278151
Posted by
そういう風にしたいよねって思うんだけど、できないことだらけ。 そんなところをがつがつと突かれる。 うんうん、ふんふんって読めて気持ちいい。 これからはもっといいコードを書こうと思うし、 書けるような気がしてくるが、 いざ書いてみるとそれは幻想でしかない。 本読むだけじゃなくて...
そういう風にしたいよねって思うんだけど、できないことだらけ。 そんなところをがつがつと突かれる。 うんうん、ふんふんって読めて気持ちいい。 これからはもっといいコードを書こうと思うし、 書けるような気がしてくるが、 いざ書いてみるとそれは幻想でしかない。 本読むだけじゃなくて、コード読まないとね。 そんなことも教えてくれて、 また読みたくなるリーダブルブックです。 (以下抜粋。○:完全抜粋、●:簡略抜粋) ○名前に情報を詰め込む(P.26) ●範囲指定はfirst/last、min/max、 包含・排他的範囲にはbegin/endを使う(P.33) ○これはあまり知られていないことである。 つまり、ここにコメントをつけるべきなのだ。(P.64) ●「コメントにはWHATではなく(あるいはHOWではなく)WHYを書こう」というアドバイスがある。 僕からのアドバイスはこうだ。 「コードを理解するのに役に立つものなら何でもいいから書こう」(P.68) ○基本的にはif/elseを使おう。三項演算子はそれによって簡素になるときだけ使おう。(P.89) ○これでネストの深さが2レベルから1レベルになった。 もっと大切なのは、精神的なスタックから「ホップ」する必要がなくなったことだ。 すべてのifブロックはreturnで終わっている。(P.95) ○このコードが言いたいのは「ユーザは文書を所持しているか?」だ。 要約変数を追加すれば、この概念をもっと明確にできる。(P.101) ○幸いなことに同じ式がいくつかあるので、 それらを要約変数として関数の最上部に抽出すればいい(これはDRY原の実例でもある)。(P.106) ○アクセスはできるだけ制限して、 変数のことが「見えてしまう」コードを減らすのがいいとされている。(P.115) ○プログラムのことを簡単な言葉で説明する技法について説明した。 説明することでコードがより自然になっていく。(P.165) ○たまには標準ライブラリのすべての関数・モジュール・型の名前を15分かけて読んでみよう。(P.172) ○平均的なソフトウェアエンジニアが1日に書く出荷用のコードは、10行なのだそうだ。(P.173) ○コーディングするよりもUnixツールボックスを使う(P.173) ○冒険。興奮。ジェダイはそんなものは求めておらん。(P.175)
Posted by
コーディングの指針となる。 読みやすくて保守性の高いコードを書くためのテクニックについて書かれている。 多少長くなったり,整形に時間をかけても,理解しやすいコードは後で保守しやすくなるとわかった。 変数名の付け方やコメントの書き方など参考になった。 個人的には,max_xとする...
コーディングの指針となる。 読みやすくて保守性の高いコードを書くためのテクニックについて書かれている。 多少長くなったり,整形に時間をかけても,理解しやすいコードは後で保守しやすくなるとわかった。 変数名の付け方やコメントの書き方など参考になった。 個人的には,max_xとするかx_max,xMax,MaxXとするか,キャメルケースやスネークケースなどの記法やコーディングの技法についても紹介・議論してくれたらありがたかった。こうした情報はあまりまとまったものがない印象。
Posted by
コードを読みやすくるTIPSがたくさん書かれている。読むコードが少なくなるように、読むときは大切なことが分かるように、コードを書くことが大切。また読もう。
Posted by
[所感] --------------------------------------------------------------- チームでの開発に携わる前に、まず読んでおきたい書籍。 本書の核となる考え方は、「読み手の気持ちになって考えたときに、読みやすいか」であると思う...
[所感] --------------------------------------------------------------- チームでの開発に携わる前に、まず読んでおきたい書籍。 本書の核となる考え方は、「読み手の気持ちになって考えたときに、読みやすいか」であると思う。 その読みやすさについて、名前、スコープ、テストなどといった切り口をもとに、構成だてて説明している。 テクニックの要約を常に見えるところに置いておいて、常に確認。 [発見・確認] ------------------------------------------------------- ■名前 ・名前に情報を埋め込む ・明確で具体的な単語を選ぶ。 ・スコープの大きな変数には長い具体的な名前をつける ・getXXXは、軽量アクセサを想定していることが多い。 ・firstとlast、beginとend ■コメント ・自分の考えを記録する。 ・ハマりそうな罠を記述 ・定数の背景を説明。 ■制御フロー ・関数から早く返す ■変数 ・変数のスコープをなるべく小さくする。 ・メソッドをなるべくstaticにすることでメンバ変数から独立し、依存性の低いメソッドを作ることができる。 ・変数には、一度だけ書き込む。でないと、現在値の判断が難しくなる。 ■無関係の下位問題を抽出 ・汎用コードを分離する。 ・ライブラリを知る ■一度に1つのことを ・コードは、一つずつタスクを行うようにする ■コードに思いをこめる ・コードの動作を、簡単な言葉で同僚にもわかるように説明する。 ■短いコードを書く ・最も読みやすいコードは、何も書かれていないコード ・ライブラリを知る - たまには標準ライブラリの全ての関数・モジュール・型の名前を15分かけて読んでみよう - 覚えろというわけではない。 ・平均的なソフトウェアエンジニアが1日に書く出荷用のコードは、10行 ■テスト ・最小のテストを作る(1行でかけるはず。コードに思いを込める参照)
Posted by