クリーンコード　第1章、第2章

# クリーンコード　第1章、第2章 ## 前書き * **小さなことに誠実であることは、決して小さなことではない！** * **プロは、小さな実践を通じて上達し、大きな実践を通じて信用を勝ち得るものである。** * **5S（整理、整頓、清掃、清潔、しつけ）** ## 第1章クリーンコード ### 混乱のために払う総コスト他人が書いたグチャグチャなコードのシステムでは、コードの変更ごとに2,3箇所コードを壊してしまう。その修正でまた別の箇所でコードを壊してしまう悪循環に陥る。チームの生産性は右肩下がりとなり、0に近づいていく。結局、基礎設計を一からやり直すことになり、エース級メンバーによる設計が行われるも、終わりが見えてくる頃にはメンバーがいなくなり、また再設計を求めるようになってしまう。 **コードの洗練は、プログラマが生き残るために重要である。** ### 良いコードを書くにはプロジェクトの失敗には、チームメンバー全員が共同責任がある。たいていの管理者は良いコードを求める。その実現のためには、スケジュールを急ぐ管理者に対し、負けない熱意を持って挑む必要がある。 **生産性を保ち、納期を守ろうとするなら、混乱を埋め込まない以外に手段は無い。** ### クリーンコード技法とは綺麗なコードを書くためには、骨身を惜しまず獲得した **「綺麗さ」のセンス**を持って、**無数の小さな手法を規律を持って適用する**必要がある。以下は有名なプログラマの言葉である。 * コードはエレガントに、かつ実行効率が最高に近いものである必要がある。（ビャーネ・ストラウストラップ, C++を開発） * エラー処理が完全でなければならない。（同上） * 一つのことをうまくやること（同上） * クリーンコードは読みやすく、うまく書かれた散文のようである。（グラディ・ブーチ, 著書に「Booch法」） * 明快な抽象化（同上）つまり純理論的かつ、事実に即さなければならない。 * 原作者以外の人も読むことができ、拡張できるコードである。（デイブ・トーマス, OTI創設者） * 常に誰かが気配りをを持って書いている（マイケル・フェザーズ） * 重複がない。（ロン・ジェフリーズ） * 1つのメソッドが何をするのかを明確にする。（同上） * 表現力を高め、単純な抽象化を早い時期に作り上げる（同上） * 自分の予想を上回るものであるとき、クリーンコードで作業をしていると言える（ワード・カニンガム, Wikiの産みの親） * 絶対的なもので、この本はクリーンコードの道場である。（アンクルボブ, 著者） ### 読みやすさは書きやすさ読み：書きの比は約10分の1程度常に既存のコードを読まなければならない。つまり、**読みやすくすることは、書きやすくすることである。** ### ボーイスカウトの原則 **キャンプ場を、自分が見つけた時よりもきれいにすること** コードは**常に洗練し続ける**必要がある。 ## 第2章意味のある名前 ### 意図が明確な名前にする **名前をつける時は注意深く、そして後でより良いものが浮かんだら、変更すること。** 何が入っているのかや、インデックス指定の意味、戻り値の重要性等、一見するとさっぱりわからないコードも、名前を変えるだけで明確に意図が伝わるコードとなる。 ### 偽情報を避ける極端な短縮形（e, hp, aix, sco等）や、型名等特別な意味を持った名前（list, final等）、わずかしか違わない名前、誤認識しやすい文字及びフォントの使用（O→ゼロ？オー？、l→いち？エル？アイ？） **偽情報（になる可能性があるもの全て）は混乱の元になるため避ける。** ### 意味のある対比を行うミススペル（String, Stirng等）、適当な順番名付け（a, b, c, a1, a2等）、定冠詞を付けただけの区別（account, theAccount等）、抽象的な単語の使用（data, info等）、意味のない区別（NameString等）、その他僅かしか差がない区別（getActiveAccount, getActiveAccounts）etc... **意味が伝わらない区別は避ける。** ### 発音可能な名前を使用する名前が呼びにくいと、長期にわたり誤った呼び名が定着してしまう恐れがある。 ### 検索可能な名前を使用する 1文字の名前だと、他のテキストと混同する可能性が高い。短すぎる文字は、for文のiなど、ローカルの一時変数のみにとどめるべきである。 ### エンコーディングを避けるエンコードされた名前を用いるのは、あらゆる面で持っての他である。 ### ハンガリアン記法あらゆる名前が、int, long, void, 文字列で型づけられている記法のこと。 Windows C APIで用いられていた記法である。 Javaでは、さらに強い片付けがなされており、型名だけで十分表現できる。この場合、名前に型を埋め込むのは避ける。 ### メンバープレフィクスメンバ変数にはm_をつけていた時代は終わり、十分な小ささのクラス・関数においては必要ない。 ### インターフェースと実装インターフェース名は単純なものにするべきである。 ### メンタルマッピングを避ける短すぎる文字は、for文のiなど、ローカルの一時変数のみにとどめるべきである。そうでない場合、コードを読む人が心の中で実概念へと変換する必要が生じる。 ### クラス名抽象的な単語の使用や動詞の利用は避け、はっきりとクラスの内容が分かる名詞句をつける。 ### メソッド名抽象的な単語の使用や名詞の利用は避け、はっきりとメソッドの内容が分かる動詞句をつける。値を操作するメソッドの名前にはgetやsetを前につける。 ### 気取らない自分しかわからないようなオシャレな名前や、ジョークのセリフ等、ウケ狙いは避け明確さを重視する。 ### 1つのコンセプトには1つの単語ある1つの抽象概念には、1つの単語を使い続けること。名前が異なると混乱を招く。整合性のある語彙は重宝される。 ### ごろ合わせをしない 1つの単語を2つの目的で使用してはならない。整合性のためにこれまでと違った意味で使おうとする人がいるが、むしろ逆効果である。 ### 解決領域の用語の使用プログラマの領域（解決領域）で使用する用語は、専門的であっても良い。 ### 問題領域の用語の使用逆に、処理内容がちっともプログラマチックでないのであれば、問題領域から持ってきた方が良い。 ### 意味のある文脈を加える単語自体が深い意味を持たない場合、**うまく名前づけされた意味のある文脈を加えて**使用する方が良い。それがない場合は、プレフィックスを付け加えて意味がある名前にする。 ### 根拠のない文脈を与えない単語補完機能の働きを邪魔するような短く大文字の連続する名前や、必要以上に文脈をつけすぎたりする使用法は避ける。 ###### tags: `読書`