ネストが深いコードは読みにくいとよく言われます。こんなコードを考えてみましょう。たしかに読みにくいですね。問題の本質――つまり読みにくい理由――はネストの深さではありません。正常終了時の流れ、つまり処理の本流がわかりづらいから読みにくいのです。上の例でいうと、本流はユーザーをグループに紐付けるところですが、こんなに大事な処理が分岐の分岐の中に書いてあります。枝の先に本来の処理を書くべきではありません。本流は「枝」ではなく「幹」に書きましょう。true;}本流がどっしりと構えてあり、例外的な処理を枝分かれで処理しているので、流れが追いやすいですね。elseはあまり使わない上の2つのコードを見比べるとわかると思いますが、elseは処理の流れを真っ二つに分けるために読みづらくなります。そのため、読みやすいコードにelseはあまり出てきません。個人的にもifはしょっちゅう書きますが、最近elseを書いた記憶は数えるほどしかありません。いって「elseは不要!」などと言うつもりは毛頭ありません。逆にelseがないと読みづらい場合もあります。詳しくは次節で説明します。本流が2つ以上ある場合はelseを使う上でこんなことを書きました。elseは処理の流れを真っ二つに分ける逆に言えば、処理の流れを真っ二つに分ける必要があるとき、つまり本流が2つあるときはelseが必要ということです。何かの値が奇数なら処理A、偶数なら処理Bと分ける場合や、A/Bテストを実装する場合などです。そんなときに以下のようなコードを書くとどうなるでしょうか。処理B}これだと、処理Aが傍流で処理Bが本流のように見えてしまいます。2つの処理の重み(長さではない)が同等でどちらも本流の場合は、elseを使って真っ二つに分けましょう。}}これで本流が2つあることが伝わりやすくなりました。付け加えるなら、処理A,Bも関数化すれば条件式部分がコンパクトになり、より流れを追いやすくなります。処理の中でさらに分岐が発生してもネストが深くならない等、いいことづくめです。目的ごとに関数化する関数の機能はできるだけシンプルにしましょう。一言で説明できるような関数がベストです。機能がシンプルであれば、組み合わせて使うのも簡単です。「指定のユーザーが所属しているグループの中で1ヶ月以上活動していないグループから脱退(紐付け削除)し、さらに別のグループにイベントを作成」なんて関数を作ったら読みにくくて仕方ない上に、名前をつけるのにも一苦労です。個人的には、しっくりくる名前をつけられない関数は設計が間違っているとすら考えています。変数・定数についてプログラムの大部分は変数の操作です。