アドベントカレンダ 厚木の民21日目担当うえだです。
みなさんが学術的に高度な文章を書いているので、ここで最後の？コーヒーブレイク！
チューターからある日突然渡された名著、リーダブルコードから印象に残った10個のフレーズを紹介します！（決して時間がなかったわけでは…うごご）
急ぎで書いたので多分後ほど追記します．
#リーダブルコードとは
これを読んだことのない人とは一緒に仕事したくない(私のチューター談)
大規模開発では、当たり前ですが他人の書いたコードを読む機会が多いと思います．コードを読み進めるだけで作業の半分、いやそれ以上の時間を割いてしまったことがある人も多いはず．
本書は
・関数が長く、変数も多いため、どう動いているかわからない
・複数の計算が1つの関数内で行われている．
等の理由で、ぱっと見でうんざりして読む気をなくさせてしまうコードの書き方を改善するテクニックが示されています．
本書を読み、実践することで少なくとも人のコードを読む時間、作業時間を短縮することができます！さらには綺麗なコードを書ける人として社内で愛されるエンジニアになれるかもしれない！スバラシー
今回は個人的に気になった内容を９つ紹介します．
もちろん全て読んだ方がいいとは思いますが、本記事を読む三分間だけでも嫌われない・呆れられないエンジニアになるくらいはできる...はず！
(すでに読んでいる人は、復習のつもりでどうぞ)
#うえだの選ぶ心に残った内容９選
####１．コードは他の人が最短時間で理解できるように書かなければならない
自分一人のプロジェクトだとしても、他の人というのは6か月後の自分自身かもしれないし、コードはいつ再利用されるかわからない．
本書の根幹を成す一言．いま自分だけが使っているからといって自分本意にコードを書いてはいけません．
####２．loop iteratorの名前付け
イテレータの命名を一般的なi.j.kにするのではなく、より説明的な名前にすることでミスを減らすことができる．
例
if(clubs[i].members[j] == users[k])
ではミスがみつけられなくても、
if(clubs[ci].members[mi] == users[ui])にしたら間違えたときにミスを見つけやすい。
個人的に目からうろこだったやつ．一般的だからと、それだけで考えなしにi.j.kで命名していませんか？一瞬の努力後々膨大な時間が節約できるかも．
####３．そのコメント、本当に必要？
コードからすぐわかることをコメントに書かない
書いたソースコードにコメントを入れるどうか、悩んだことはありませんか？単なるコードの動作の説明等は読めばわかるのでコメント不要です．何のための関数であるかなど、新しい情報を提供するのみにしましょう．
####４．ライターズブロック(うまく表現できないコメントを書きたがらない習慣)を乗り越えろ
書き方が見つからないコメントは自分の思っていることをとりあえず書き出してみる．
（やばい。これはリストに重複があったら面倒ごとが起きる 等）
言い回しを詳細な言葉に置き換えればそのまましっかりしたコメントになる．
コメントを書こうとするもののうまい表現がみつからないとき、放置してしまうあるある．書き方がわからなかったら思っていることを口語でもなんでも書いてみて、そこから整理しましょう．
####５．if/elseブロックの並び順
関心を引く条件を先に書くことで、脳内リソースを節約できる
単純な条件を先に書くとif/elseが同じ画面上で表示され、わかりやすい
思いついた順にif/elseブロックを並べてしまうと、無駄に脳内リソースを割いてしまうとのこと．
####６．ネストを浅くする
ネストの深いコードは"精神的スタック"に条件をプッシュする必要が増え、無駄な脳内リソースを使うので、できるだけネストを浅くすること。
変数を追っていくうちに何が何だかわからなくなって最初から追いなおす、少なくとも私はよくやってしまいます．大規模開発ではどうしてもネストは深くなりがちですが、その中でも最小限に抑える努力をしましょう．
####７．変数のスコープをできるだけ小さくする
グローバル変数を多用すると、どこでどのように使われるか追跡できなくなったり、ローカル変数と衝突したりハンドルするのが難しくなる．そのため、すべての変数のスコープをできるだけ縮める必要がある．
スコープ広げすぎで自分がどんなものを扱っているのかわからなくなる、大規模開発あるあるですね．勿体なく感じるかもしれませんが、あえてスコープを狭めて変数を掌の上で転がしましょう(笑)
####７．無関係の下位問題を積極的に見つけて抽出する
関数やコードブロックの高レベルの目標を考え直し、コード中からその目標に直接関係のない部分を抽出し、別関数にするだけでコードを大幅に改善できる。
これも大規模開発あるある、ソースコードなずらずら書きがち問題．問題の切り分けをしっかりしてコードがすっきり読みやすくなります．
####８．コードは１つずつタスクを行うようにしなければならない
読みにくいコードがあればそこで行われているタスクを全て列挙し、別の関数やクラスに分割する．
すると、ある領域にいるときにほかの領域のことを考えずに済むようになる．
７とほとんど同じですね．タスクごとに関数を分割し、脳内リソースを節約しましょう．
####９．コードの重量を意識する
開発規模が大規模になればなるほど、すべてを把握できる人は誰もいなくなり、結びつきが複雑になることでコードの扱いは厄介になる．
未使用コードを削除するなどコードの全体の重量を意識する必要がある．
勿体ない精神は時に身を滅ぼします．ソースコードがさながらゴミ屋敷になる前にこまめにコードを整理しよう．
#おわりに
以上9個並べてみましたが、いかがでしたか？
ソースコードで会話するソフトウェアエンジニアとして(最近ソフトの人ってコード上で会話するんでしょ〜？って言われた)、だれしもが読みやすいコードを書ける愛されエンジニアになれるよう頑張りましょう！
リーダブルコードのご購入はこちらから。(すぐよめるのでぜひ)
クリスマス近くなってきましたね、皆さん良いクリスマス年末を！
#ちなみに
年末年始に見るべき映画はこれ．