リーダブルコードを読む part7
こんにちはかわです。
アドベントカレンダー２２記事目
前回の続きです
7章 制御フローを読みやすくする
1 条件の引数の並び順
| 左側 | 右側 |
|---|---|
| 「調査対象の式」。変化する。 | 「比較対象の式」。あまり変化しない。 |
2 if/elseのブロックの並び順
- 条件は否定型より肯定形を使う。
- 単純な条件を先に書く。ifとelseが同じ画面に表示されるので見やすい。
- 関心を引く条件や目立つ条件を先に書く。
この優劣は衝突することがあるため、臨機応変に対応する。
3 三項演算子
行数を短くするよりも、他の人が理解するのにかかる時間を短くする。
基本的にはif/elseを使う。三項演算子は簡潔になるときだけ使用する。
4 do/whileループを避ける
do/whileのループは書き直せることが多い
何のループかをわからせるためにも先に書いたほうがいいかも
5 関数から早く返す
関数から早く返すことはいいことらしい。
returnを１つにしたいということは、
何らかのクリーンアップコードを実行したいから？
関数終了後に呼び出されるコードは各言語あるので調べてみるといい。
6 悪名高きgoto
c言語以外ではgotoは必要ない。
ー＞同じことをする方法が他に存在するから。
基本的には使うな
7 ネストを浅くする
ネストが増える仕組み
機能を追加する際、コードを最も挿入が容易な場所に挿入した結果、
ネストが増えることが多い。
早めに返してネストを削除する
ネスト内部のループを削除する
ループ内で早めに返す場合continueを使う。
ただしcontinueはループを行ったり来たりするためわかりにくい。
気をつけるべき。
8 実行の流れを追えるかい？
プログラムの高レベルの「流れ」についても考えなくてはいけない。
| 構成要素 | 高レベルの流れが不明瞭になる理由 |
|---|---|
| スレッド | どのコードがいつ実行されるかわからない |
| シグナル/割り込みハンドラ | 他のコードが実行される可能性がある |
| 例外 | いろんな関数呼び出しが終了しようとする |
| 関数ポインタと無名関数 | コンパイル時に判別できないので、どのコードが実行されるのかわからない |
| 仮想メソッド | object.virtualMethod()は道のサブクラスのコードを呼び出す可能性がある |
これらの構成要素を利用することで、コードが読みやすくなったり、
冗長性が低くなったりすることがある。
ただコード全体に占める割合を大きくしないことが大切。
以上
リーダブルコードを読む part6
こんにちはかわです。
アドベントカレンダー２１記事目です。
前回の続きです。
6章 コメントは正確で簡潔に
コメントは領域に対する情報の比率が高くなければならない
1 コメントを簡潔にしておく
少ない領域ですむように推敲する
2 曖昧な代名詞を避ける
代名詞はなるべく避けるように努める。
代名詞が何を指すかを明確にすべし。
3 歯切れの悪い文章を磨く
語彙力を磨く
4 関数の動作を正確に伝える
なるべく詳細に伝える。
コメントを読む人の誤解を減らすため。
5 入出力のコーナーケースに実例を使う
コメントが長文になる際には実例を使うべし。
ただし、簡単な実例では役に立たないので、
想定される質問に応えられる実例を書く。
6 コードの意図を書く
コードの動作をそのまま書くのではなく、高レベルから説明するのもあり。
その結果、コードが作者の意図に反しているかどうか見つけやすくなる。
7 「名前付き引数」コメント
これはコメントのような効果があるため使ったほうがいい。
Connect(/* timeout_ms */ 10);
8 情報密度が高い言葉を使う
説明が長くなった場合、専門用語等を使用して短くできないか検討する。
以上
リーダブルコードを読む part5
こんにちはかわです。
アドベントカレンダー２０記事目です。
前回の続きです。
5章 コメントすべきことを知る
コメントの目的は、書き手の意図を読み手に知らせることである。
- コメントするべきでは「ない」ことを知る。
- コードを書いているときの自分の考えを記録する。
- 読み手の立場になって何が必要になるかを考える。
1 コメントするべきでは「ない」こと
コードからすぐわかることをコメントに書かない
例 swift
//Humanクラスの定義
class Human{
private var age = 0
private var name = ""
//イニシャライザ
init(_ n: String,_ a: Int){
name = n
age = a
}
func hallo() {
print("Hallo")
}
//ageの値を返すメソッド
func Age() -> Int{
return age
}
//nameの値を返すメソッド
func Name() -> String{
return name
}
}
コメントのためのコメントをしない
コードからわかるコメントをしない
コードからわからないこと（処理の内部等）を記述（大切なことのみ）
ひどい名前はコメントをつけずに名前を変える
変数名やメソッド名等を変えることで理解が深まる際には、
コメントをつけず、変数名やメソッド名を変更する。
優れたコード > ひどいコード + 優れたコメント
2 自分の考えを記録する
思ったことややってみたことは積極的にコメントする
コメントをする際によく使う記法
| 記法 | 典型的な意味 |
|---|---|
| TODO: | あとで手をつける |
| FIXME: | 既知の不具合があるコード |
| HACK: | あまりキレイじゃない解決策 |
| XXX: | 危険！ 大きな問題がある |
上記の記法、チームの規約を作ることでコメントがわかりやすくなる
定数にコメントを付ける
定数を定義する際その定数が何をするか、
なぜその値にしたのかを記述した方がいい。
定数の「背景」を記述する。
3 読み手の立場になって考える
プロジェクト外の人から質問されそうなことを予測し、コメントを残す。
コードを見て間違う可能性のあるもの、他の人が見たら驚くことを
コメントに残す。
ソースコードを見ただけでは得られないこと（依存関係や実際やっている事）
はファイルにコメントを付ける。（短いもので大丈夫）
関数内部でも処理ごとで要約コメントを書く。
ー＞詳細を調べなくても関数の概要を理解できるようにするため
4 ライターズブロックを乗り越える
手順として以下を繰り返す。
頭のなかにあるコメントをとにかく書き出す
コメントを読んで改善が必要なものを見つける
改善する
以上を繰り返し行うことでコメントの質はあがっていく
