触ってない言語、機能について書かれている今必要なさそうなところは飛ばして、自分（初心者）がすぐに実践できそうな知識についてまとめてみました。

優れたコードとは？？

他者が読んで理解できるコード。
コードは短い方がいいが、『理解するまでの時間』を短くする方がよい。
そのため短くすることで逆にわかりにくくなるようであれば短くする必要はない。

名前に情報を詰め込む

変数や関数、クラス名でも名前に情報を詰め込むのが大事。名前は短いコメントのようなもの。

• 明確な単語を選ぶ
  getPageだと何のページをgetしているかわからない。インターネットから取ってきたページなら、downLoadPage等の方がわかりやすい。

• tmpやretvalなどの汎用的な名前は避ける。
  明確な理由があれば使用してもいい。

• 抽象的な名前より具体的な名前を使う

• 変数名に大切な情報を追加する
  ミリ秒を表す変数なら、変数名の後ろに_msとつけると何の変数かわかりやすい。

• 名前の長さを決める

• スコープが小さければ短い名前でも良い。

• 頭文字と略語
  string⇨strなど他人にも通じる略語を使うのがいい。BackEndManager⇨BEM等、他の人がわからない略語はNG

• 不要な単語は捨てる
  DoServeLoop（）だったら、ServeLoop()でも必要な情報は損なわれてないのでOK。なくても通じる単語は捨てる。

• 名前のフォーマットで情報を伝える
  エンティティごとに異なるフォーマットを使う。
  C++言語であれば、クラス名はキャメルケース、変数名は小文字にしてスネークケースで定義する、など。
  ローカル変数とクラス変数も、異なるフォーマットで書くと一目見て何かわかるので良い。

• その他フォーマット規約
  プロジェクトや言語によってもフォーマット規約は変わってくる。
  JavaScriptでは、jQueryのライブラリ関数を呼び出したときは、変数名の頭に$をつけるというものがある。⇨iQueryのオブジェクトだと明確にわかるため。
  HTMLだと、タグのid名の区切り文字にはアンダースコアを、class名の区切り文字にはハイフンを使う規約が有力。

誤解されない名前をつける

自分のコードを読んでいる人が、自分の意図を正しく理解できることが大事。

• 限界値を含め場合はminとmaxを使う。
  CART_TOO_BIG_LIMITという名前だと意味があいまい。（未満なのか以下なのかがわからない）⇨MAX_ITEM_IN_CARTのほうが意味が伝わりやすい。

• 範囲を指定する場合はfirstとlastを使う
  startは適切な名前になるが、stopは複数の意味に解釈できるため、firstとlastを使用する方が適切。

• 包含/排他的範囲にはbeginとendを使う

• ブール値（真偽値）の名前
  read_passward = true
  パスワードをこれから読み取る？もう読み終わっている？適切な名前ではない。
  user_is_authenticated = true
  こっちのほうが適切。また、名前を否定形ではなく肯定系にしたほうがよい。

• ユーザーの期待に合わせる
  getで始まるメソッドだとメンバの値を返すだけの軽量アクセであるという規約がある。
  この規約を守らないと、DBからすべてのレコードを取ってくるときの変数名にgetをつけたりすると、間違って使用したりしてコストが高くなってしまう。

• 複数の名前を検討する

コードの美しさ

• 一貫性のある簡潔な改行位置

• メソッドを使った整列

• 縦の線をまっすぐにする

$aaa     =  "test";
$b       =  "test";
$cccccc  =  "test";

イコールの位置を合わせると見やすい。

• 一貫性と意味のある並び
  アルファベット順にしたり、「最重要」なものから重要度順に並べたり、対応する HTML フォームの フィールドと同じ並び順にするなど。

• 宣言をブロックにまとめる

• コードを段落に分割する
  文章と一緒。見やすくなる。

-　個人的な好みと一貫性
クラス定義のカギカッコの位置など、最終的には個人の好みによる部分が大きい。
間違ったスタイルを使っているプロジェクトもあるが、その場合はプロジェクトの規約に従うのが大事。
一貫性の方が重視される。

コメントすべきことを知る

• コメントすべきではないことを知る
  コードを見てわかることは書かない。関数の名前と同じことを日本語でコメントアウトするなど

• ひどい名前はコメントをつけずに名前を変える
  コメントで説明するくらいなら、関数等の名前をもっとわかりやすい名前に変える。
  関数名等はいろんなところで使用されるため、そっちを変えた方がよい。
  「優れたコード > ひどいコード + 優れたコメント」

• 自分の考えを記録する
  優れたコメントというのは「考えを記録する」ためのものである。
  たとえばこんなの

// このデータだとハッシュテーブルよりもバイナリツリーのほうが 40% 速かった。
// 左右の比較よりもハッシュの計算コストのほうが高いようだ。

コメントから情報を得ることができ、下手に最適化しようとして時間を無駄に使う必要がなくなる。
コードが汚い理由を書いてもいい。

• コードの欠陥にコメントをつける プログラマがよく使う記法

• 定数にコメントをつける
  定数を定義するときはなぜその値を持っているかという背景を持っている

• 読み手の立場になって考える

- 「全体像」のコメント

# 顧客が自分で購入した商品を検索する

このような、全体像が掴めるコメントをしておく。