IF文がネストする場合はまずガード条件でネストを解消できないか検討する。IF文がネストするような状況は大抵ガード条件で回避できる。
IF文の条件式が複数あり複雑化している場合は、条件式そのものをメソッドにする。条件式を切り出したメソッドはガード条件を使って更にわかりやすくすることができる。
長いメソッドはロジックを追うことが実際難しい。30行程度なら認知負荷も少なく済む。
メソッド中で特定の処理のためのブロックが存在する場合、その処理は別メソッドに切り出すべきである。
データの取得と加工をひとつのメソッドで行うと後の仕様変更に非常に弱くなる。データ加工ロジックに様々な条件式が混入し、理解不能のコードになってしまう。
そのため、データ取得と加工は別のメソッドで行うのが良い（単一責務原則）。
ひとつのモジュールに存在するメソッドは12個を上限とする。それ以上メソッドが存在する場合、モジュール自体の責務が大き過ぎると考えるべきである。
メソッドの仕事はひとつだけに限定する（単一責務原則）。
参照渡しはその定義上参照透過性を破壊する。一方、関数（メソッド）の可読性・保守性については参照透過性が担保されている方が良い。優先されるべきは可読性・保守性であるため、参照渡しによる変数の受け渡しをしてはならない。
参照渡しでスコープ外（関数外）の変数に影響を与えるコードは実質的にグローバル変数と同じ性質を持つため、極力これを避けるべきである。
引数を変更した値を返したい場合は素直にreturn値で返却する関数（メソッド）を作るべきである。
変数（クラス、構造体）をコピーする事によるパフォーマンス劣化に関しては、(1)そもそも巨大な構造体を作らない、(2)一部を切り出せるようにする、などの工夫を検討するべき（神クラスの排除）。
ループが二重にネストした処理では内側のループブロックを関数に切り出した方がよい。外側のループで行われる処理と内側のループで行われる処理は異なる責務を持った処理と見なすことができるからである。
ただし、ループのネストは二重までに留めるべきであり、三重以上のループはそもそものデータ構造を再検討するべきである。