SQL SERVER intの剰余算
intどうしで割り算などをすると計算後の値が小数点以下が切り捨てられてしまう。
左辺もしくは右辺をfloatにCONVERTすると小数点以下も出力される
本 リーダブルコード
リーダブルコードまとめ
第０部
1章 理解しやすいコード
鍵となる考え「コードは理解しやすくなければいけない。」
- 「簡潔であること」と、「安心できること」どちらが大切？
- その評価基準の鍵となる考え「コードは他の人が最短時間で理解できるように書かなければいけない。」
- その「他の人」は未来の自分自身でもある
- 1行のコードを2行にして理解する時間が早くなるなら2行にしろ（同じだけのメモリを使う場合）
- このコードは理解しやすいだろうか、と常に問いかけるのが大事
第Ⅰ部 表面上の改善
- 優れたコメントや綺麗なフォーマット、適切な名前。表面上の改善をこつこつするだけで大きな改善をもたらせる。
2章 名前に情報を詰め込む
鍵となる考え「名前に情報を詰め込む」
6つのテーマ
- 明確な単語を選ぶ
- 例：「get」はあまり明確な単語ではない。「Fetch」や「Download」などより明確な単語を使うべき。
- 汎用的な名前を避ける（あるいは、使う状況を選ぶ）
- 汎用的な名前（例：tmp、retval）
- もしこれらの汎用的な名前を使うのであれば、それ相応の理由を用意しよう
- 少しでも時間を使っていい名前を考える習慣をつけて、「命名力」を高めよう
- 抽象的な名前よりも具体的な名前を使う
- 例：「run locally」ではなく「extra logging」として直接的で明確な名前を使用
- 接尾辞や接頭辞を使って情報を追加する
- 値の単位や、重要な属性を追加する
- 例：ミリ秒であることを追加「ms」、エスケープする必要があるユーザー入力コメント「unescaped_comment」等
- 値の単位や、重要な属性を追加する
- 名前の長さを決める
- 長すぎる名前はダメ。覚えにくえい、画面占領する、コード行が無駄に増える。が、具体的な名前であるのも大事。
- スコープが小さければ短い名前でもいい
- 不要な単語を捨てる。「ConvertToString」は「ToString」でも通じる
- 名前のフォーマットで情報を伝える
- クラスのメンバにはアンダースコアをつける、jQueryのオブジェクトでは$を使う等
3章 誤解されない名前
- 「filter」というメソッドは、その返り値が「選択された値」なのか「除外された値」なのかわからない
- 「limit」というあいまいな原数名を使って境界値のバグを生み出してしまう→「max」を使う
- 「start」と「stop」、「stop」は値を包括しているのかあいまい。「first」「last」であれば包括しているか明白
- Bool値は、is, has, can, should などを使用してわかりやすくする
- Bool値は否定形を避ける。「disable_ssl」よりも、「use_ssl」。
4章 美しさ
- 見た目が美しいコードは使いやすい
- 縦を揃えるなど紹介されているが、要は整形ツールを使えばOK
5章 コメントすべきことを知る
- コメントの意図は、「書き手の意図を読み手に知らせることである」
- コードからわかることをコメントに書かない
- コメントを書くのではなく、関数名変数名を変更できないか考える
- 自分の考えを記録する。
- 例：「このデータだとハッシュテーブルよりもバイナリツリーの方が40%早かった。左右の比較よりもハッシュの計算コストの方が高いようだ。」
- 例：「ヒューリスティックだと単語が漏れることがあるが仕方ない。100%は難しい。」
- 例：「このクラスは汚くなってきている。サブクラスResourceNodeを作って整理した方がいいかも知れない。」
