xxxさんの備忘録

xxさんのブログです.xxさんはネカマです.

リーダブルコード (第三部)

読んだ

#3部
##10無関係の下位問題を抽出する
関数やコードブロックを見て、「このコードの高レベルの目標は何か？」と自問する
コードの各行に対して「高レベルの目標に直接的に効果があるのか？あるいは無関係の下位の問題を解決しているのか？」と自問する
無関係の下位問題を解決しているコードが相当量あればそれらを抽出して別の関数にする。

・入門的な例
→完全に自己完結しているのでどのアプリケーションで使われるかを必要としない。
・純粋なユーリティコード
→「このライブラリーにXYZ関数があればなぁ」と思ったらその関数を自分で書く。そうしたコードは複数プロジェクトで使えるユーティリティコードになっている
・その他の汎用的なコード
→関数は小さく独立したものになっていれば、機能追加・読みやすさの向上・エッジケースの処理などが楽にできる
・汎用コードをたくさん作る
→プロジェクトから完全に切り離されているため、開発やテストに役立つ。
・プロジェクトに特化した機能
→抽出する下位問題はプロジェクトから完全に独立している必要はない、下位問題を取り除くだけでも意味はある
・既存のインターフェースを簡潔にする
→「理想とはほど遠いインターフェイスに妥協すること」はないようにする。
・必要に応じてインターフェイスを整える
・やりすぎは避ける
→小さな関数を作りすぎてしまうとあちらこちらに飛び回る実行パスを追いかけることになるため、避ける。
・プロジェクト固有のコードから汎用コードに分離させることが大事

## 11一度に1つのことを
コードは1つずつタスクを行うようにしなければならない。
これを「一度に1つのタスクをする」と呼び手順は以下のようになっている。
    1.コードが行っているタスクを列挙する。
    （タスク ex.「オブジェクトが妥当かどうかを確認する」や「ツリーのすべてのノードをイテレートする」など）
    2.タスクをできるだけ異なる関数に分散する。少なくとも異なる領域に分離する。

実例）
    ・タスクは小さくできる
    ・オブジェクトから値を抽出する

・まとめ
→読みにくいコードがあればそこで行われているタスクをすべて列挙する。

## 12コードに思いを込める
コードをより明確にする簡単な手順として
    1.コードの動作を簡単な言葉で同僚にもわかるように説明する
    2.その説明で使っているキーワードやフレーズに注目する
    3.その説明に合わせてコードを書く
・ロジックを明確に説明する
→否定形を減らし、権限がある人がより分かりやすいコードに直した
・ライブラリを知る
→簡潔なコードを書くのに欠かせないのはライブラリが何を提供してくれているかを知ること
・この手法を大きな問題に適用する
→解決策を言葉で説明する。手法を再帰的に適用する
・まとめ
→プログラムのことを簡単な言葉で説明することで問題のある下位問題に気が付くことができる。
ex.ラバーダッキング 人形などに問題を声に出して説明する手法（cf 『プログラミング作法』、『達人プログラマー――システム開発の職人から名匠への道』など）

## 13短いコードを書く
最も読みやすいコードは、何も書かれていないコードである

・その機能の実装について悩まないで
→実装にかかる労力を過小評価してしまうことで、「負担」の比率が上がってしまう
・質問と要求の分割

・コードを小さく保つ（コードをできるだけ小さく軽量に維持する）
→
汎用的な「ユーティリティ」コードを作って重複コードを削除する
未使用のコードや無用の機能を削除する
プロジェクトをサブプロジェクトに分割する
コードの「重量」を意識する。軽量で機敏にしておく

・身近なライブラリに親しむ
→標準ライブラリのすべての関数・モジュール・型の名前を読んでみる
どんなことができそうかを目を通しておく

・例：コーティングするよりもUnixツールボックスを使う
サーバーが4xx,5xxを返したときのURLパスを見つけるプログラムをJava等実装をしようとすると20行以上になってしまう。
Unixならば、コマンドを入力するだけで済む
（またソース管理もに含む費用もなくなる）

・まとめ
できるだけコードを書かないことを説明した。
新しいコードを書かないようにするには
１）不必要な機能をプロダクトから削除する。過剰な機能は持たせない
２）最も簡単に問題を解決できるような要求を考える
３）定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく

リーダブルコード (第ニ部)

読んだ

#2部

##7制御フローを読みやすくする
条件やループなどの制御フローを読みやすくする。
・条件式の引数の並び順
ex.左側（調査対象の式）,右側(「比較対象」の式。あまり変化がない)
・if/elseブロックの並び順
→・条件は否定よりも肯定系を使う
・単純な条件を先に書く。（ifとelseが同じ画面に表示されるように書く）
　・関心を引く条件や目立つ条件を先に書く
これらを状況によって判断し注意していく。
・三項演算子
他人が読んで理解するのに時間のかからないコードを意識する
・do/whileループを避ける
・関数から早く返す
・悪名高きgoto(gotoは基本的には使わない)
・ネストを浅くする
・実行の流れで複雑になる例（バグの発見が難しくなるものなど）
→スレッド、シグナル/刷り込みハンドラ、例外、関数ポインタと無名関数、仮想メゾットなど

##8巨大な式を分割する
コードの式が大きくなれば理解が難しくなる。
→巨大な式はわかりやすい大きさに分割する

・説明変数
式を表す変数を使用する

・要約変数
大きなコードの塊を小さな名前に置き換えて、管理や把握を簡単にする変数のことを要約変数と呼ぶ。

・ド・モルガンの法則を使う
・短絡評価の悪用
→短いコードよりも、あとで人が読んでわかりやすいものを目指す。
・複雑なロジックと格闘する
→「反対」から問題を解決してみる（ex.「重なる値」を求めていた場合には「重ならない」方を考えるなど）
・巨大な文を分割する
(・式を簡潔に書く方法→マクロを定義する)

##9変数と読みやすさ
変数を適当に使うと理解しにくくなる。
→変数が多いと変数を追跡するのが難しくなる
　変数スコープが大きいとスコープを把握する時間が長くなる
　変数が頻繁に変更されると現在の値を把握するのが難しくなる

・変数を削除する
→コードが読みやすくならない変数を削除する
　・約に立たない一時変数（複雑な式を分割していない。より明確になっていない。一度しか使っていないため重複コードの削除になっていない）

→中間結果を削除する

→制御フロー変数を削除する

→△変数スコープを縮める（※用例が多いがいまいちわかってない）
　・変数のことが見えるコード行数をできるだけ減らす。

・変数は一度だけ書き込む
→変数を操作する場所が増えると、現在の値の判断が難しくなる

リーダブルコード (第一部)備忘

読んだ

＄1、理解しやすいコード
・読みやすさの基本定理
　・コードはほかの人が最短時間で理解できるように書く
＄2、名前に情報を詰め込む
・明確な単語を選ぶ（気取った言い回しよりも正確。明快さを求める）
ex.get→どこから？わかりにくい。
インターネットからFetchPage、DownloadPageなど
・汎用的な名前を避ける（理由がない場合には避ける）
tmp という名前は、生存期間が短くて、一時的な保管が最も大切な変数にだけ使用
for文iはそれだけでは何を指しているのかわからない場合もあるので場合によってはmember_i等にしてもよい
・抽象的な名前よりも具体的な名前を使う
ex,run_locally→ローカル以外でも使用する可能性などから分かりにくい。-

  • extra_loggingとオプションでlocal_databaseを用意した。

・接尾や接頭を使って情報を追加する
値の単位として（ms,secなどを尾につける）
変数の意味を間違えるとバグが起きそうな箇所にはutf8や
・名前の長さを決める
プロジェクト固有の省略は相手が初見の場合、暗号のように見えるため避けるべき。
・名前のフォーマットを情報で伝える
exクラスのメンバ変数にアンダースコアを付けてローカル変数と区別するなど
$3、誤解されない名前
・名前が他の意味と間違えられることはないかと考慮する
・cf:”filter”→除外するか選択するかわからない。
選択する→select、除外する→exclude
・cf”Clip(text,length)”→"Trucate"もしくはremove切り取りにかえるほうがいい。
length→・バイト数、文字数、単語数 というように様々な解釈ができるため、明確にするべき
・限界値を含めるときはmin,maxを使う
・範囲を指定する時はfirstとlastを使う
・包含/排他的範囲にはbeginとendを使う
・ブール値（boolearn）の名前や値を返す変数はtrue,falseがどうなっているかを明確に分かる形で命名するべき
　また、否定より肯定のほうが明白なことが多い
・ユーザーの期待に合わせる
(get,sizeは軽量なメソッドが期待されいている)
・最善の名前について考えるとき、それらは誤解しない名前を考えることにつながる。
→コードを読む人が意図を正しく理解できるように。
4美しさ
・読み手が慣れているパターンと一貫性のあるパターンを使う
・似ているコードは似ているように見せる
（ex.一貫性のある改行位置など）
・関連するコードはまとめてブロックにする
(ex.読みやすい論理的なグループに分けるなど)
→美しいコードのほうが読むために使う時間が少なくて済む

5コメントすべきことを知る
・コメントすべきではないことを知る
→コードからすぐわかることをコメントに書かない
・ひどい名前はコメントを付けずに名前を変える
→一読しただけでわかるような命名を心掛ける
・自分の考えを記録する
→情報のあるコメント（計算の調査についてなど）
→//TODO:(コードの欠点を記録する)など
→定数にコメントを記録する
・読み手の立場になって考える
プロジェクトを熟知していなくとも読めるコードを目指す。
→質問されそうなことを想像する
・ライターズブロックを乗り越える
→ともかく必要だと思ったことは書いたほうがいい

6コメントは正確に簡潔に
コメントは領域に対する情報比率が高いほうが好ましい
・コメントは簡潔にしておく
・曖昧な代名詞は避ける
・関数の動作を正確に記述する
△入出力のコーナーケースに実例を使う
・コードの意図を書く
→ex 「listを逆順にイテレートする」よりも「値段を高い順に表示する」のほうが
プログラムの動作を高いレベルから説明している
・「名前付き引数」コメント
→よくわからない引数にコメントを付ける
ex.
(/*timeout_ms = */10, /* use_encryption = */ false)
・情報密度の高い言葉を使う
→正規化のようにわかっていて短くできるような言葉がないかを確認する （編集済み）


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

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

学習記録_days41-50

番号が抜けるので変えてみた。

何やってたかがわかれば問題ないところもあるので

code書いてないじゃん……って感じだ。

 

学習記録_31~40

学習記録メモ

(day38,day36見つからない)

https://twitter.com/fallakiakino/status/1163849997206470656 Tue, 20 Aug 2019 16:27:17 +0000 (40/100)
progate html&css 初級編　
1.5　ヘッダーの余白
#100DaysOfCode
https://twitter.com/fallakiakino/status/1163514556976492550 Mon, 19 Aug 2019 18:14:22 +0000 (39/100)
jsファイル修整
#100DaysOfCode
https://twitter.com/fallakiakino/status/1162819346592235520 Sat, 17 Aug 2019 20:11:51 +0000 (37/100）
JavaScriptソース修整
#100DaysOfCode
https://twitter.com/fallakiakino/status/1162042160989921286 Thu, 15 Aug 2019 16:43:35 +0000 (35/100）
ruby on rails  チュートリアル 1.3.1まで
#100DaysOfCode
https://twitter.com/fallakiakino/status/1161663124165935104 Wed, 14 Aug 2019 15:37:26 +0000 （34/100）
Laravel入門
一周目完了（あんまりわかってないからまた読むかもしれない??）
#100DaysOfCode
https://twitter.com/fallakiakino/status/1161292291853524992 Tue, 13 Aug 2019 15:03:52 +0000 （33/100）
Laravel入門
next p325 ユニットテスト
#100DaysOfCode
https://twitter.com/fallakiakino/status/1161010639638155264 Mon, 12 Aug 2019 20:24:41 +0000 （32/100）
Laravel入門
next p315 ユーザー認証
#100DaysOfCode
https://twitter.com/fallakiakino/status/1160577938070200322 Sun, 11 Aug 2019 15:45:17 +0000 （31/100）
Laravel入門
next p311 paginateメソッドの利用
#100DaysOfCode

学習記録_days21-30

(day21,day24,day28,day29が見当たりませんがとりあえず)

 

https://twitter.com/fallakiakino/status/1160253193588133888 Sat, 10 Aug 2019 18:14:52 +0000 (30/100)
Laravel入門
next p280 RESTfulサービス
#100DaysOfCode
https://twitter.com/fallakiakino/status/1159140205925826561 Wed, 07 Aug 2019 16:32:15 +0000 (27/100)
Progate　2レッスン程度
#100DaysOfCode
https://twitter.com/fallakiakino/status/1158776002668986368 Tue, 06 Aug 2019 16:25:02 +0000 (26/100)
Progate
PHP 道場コース Ⅰ　終了まで
#100DaysOfCode
https://twitter.com/fallakiakino/status/1158403847510827008 Mon, 05 Aug 2019 15:46:14 +0000 (25/100)
Progate
PHP1 道場コース　8ページ
#100DaysOfCode
https://twitter.com/fallakiakino/status/1157695314163146753 Sat, 03 Aug 2019 16:50:46 +0000 (23/100)
Laravel入門
次回 シーダーファイルの作成　
#100DaysOfCode
https://twitter.com/fallakiakino/status/1157360047560613888 Fri, 02 Aug 2019 18:38:32 +0000 (22/100)
Laravel入門
クエリビルダまで
次回 p213 マイグレーションとシーティング
#100DaysOfCode

メモ_週末行ってたところなど

行った

2019/08/31

connpass.com

 

2019/09/01

weeyble-creative.connpass.com

 

に行って、Rails チュートリアルやってた

第３章(3.6)の簡単なテストの実施までを動かした。

 

とりあえず以上で。