自分が今どのスコープにいるかわからなくなります。見やすくないと内容の理解が遅れます。その分、実装にも遅れが出ます。「期日」という悪魔を追い払う一手に減らせる階層は減らしましょう!サンプル、一応書いておきますね。(もう言わずもがなだとは思いますが・・・。)学生の頃に書いていただろうコードになりました。(いい案が浮かばなかったです・・・。要約変数、おそらく変数を作る際は基本的にこの変数になるのではないかなと思います。要約変数はどんな式なのか(またはその結果)を入れるのに使うものじゃないかなぁと考えています。どちらにも共通しているのは、できるだけ短い名前でそれが何なのかを伝える必要がある。いうことではないでしょうか。いえプロジェクト固有の略称なんかは使うべきではないですよね。私もできるだけ、そうできるように気をつけてはいます。笑)こういうのはもう、センスとボキャブラリーの産物ですよ・・・。何が入っているかわからない玉手箱になるくらいなら、ある程度の名前の長さを許容して、ガラスの箱にでもする方が役に立つ変数が作れます。説明変数は演算に、要約変数は制御式に使うとシチュエーション的にも良さげだと思っています。今の時点でも早速業務に反映できるものが多かったですね。新人の頃はコード規約を覚えたり、新しい言語に慣れたりで、なかなかコード品質にまで目が向かないと思います。そんな人こそ一度読むといいかもしれないですね。笑)ちなみにですが、この本の前にリファクタリングの本を読みましたが、リーダブルコードはリファクタリングに通づる内容があるなとも感じました。この本を読みきるまではまた、幾つか紹介ができればと思います。それでは今回はここまで。採用情報クラウドクリエイティブスタジオではエンジニアの方を絶賛募集中です。