リーダブルコードを読む part4
こんにちはかわです。
アドベントカレンダー１９記事目です
以下の続きです。
4章 美しさ
- 読み手が慣れているパターンと一貫性のあるレイアウトを使う
- 似ているコードは似ているように見せる
- 関連するコードはまとめてブロックにする
1 なぜ美しさが大切なのか？
見た目が美しい方が使いやすい
ー＞プログラミングの時間のほとんどはコードを読む時間だから
流し読みしやすいコードを心がける
2 一貫性のある簡潔な改行位置
一貫性をもたせるために適切な位置に改行、コメントも整列させる
3 メソッド使った整列
同じメソッドを引数を変えて複数使っている場合、
ヘルパーメソッドを使用することでコードを整形し直した。
この章の例では変更の効果として、
- 重複を排除したことでコードが簡潔に
- 重要な部分が見やすくなった
- テストの追加が簡単になった
見た目を良くすることは表面上の改善だけではなく、
コードの構造も改善できる。
4 縦の線をまっすくにする
例
//hoge(a, b, c) a:String b:Int c:float という関数があるとする。
hoge("hello", 500 , 1.2)
hoge("world", 4000, 3.14)
hoge("kawa" , 10 , 109.8)
//二番目、三番目の引数がわかりやすくなる
縦の線が「視覚的な手すり」になれば流し読みがし易い効果がある。
似ているコードは似ているように見せる効果がある。
5 一貫性と意味のある並び
コードの並びがコードの正しさに影響することは少ないが、
ランダムに並べるより、意味のある順番に並べるべき場合もある
- 対応するHTMLフォームの
<input>フィールドと同じ並びにする - 「最重要」なものから重要度順に並べる
- アルファベット順に並べる
以上の並べ方がある
また、一連のコードでは同じ並び順を使うべし
email = "・・・・@・・・.com" phone = "0123456789" url = "・・・.com" print(phone) //この順番だとあとでわからなくなる print(email) print(url)
6 宣言をブロックにまとめる
宣言をする時、
メソッドの働きごとに分けて宣言することで、
概要が把握しやすくなる
7 コードを「段落」に分割する
コードの機能ごとに段落を作るべし。
その際にコメントを記入するとコードをざっと目に通しやすくなる。
8 個人的な好みと一貫性
個人的な好みがコードに反映される場合がある。
class hoge{
・・・
}
class hoge
{
・・・
}
どちらを選んでもいいが、
２つのスタイルを混ぜてしまうと読みにくくなる
スタイルを一貫することが大事
以上
2017年 反省
こんにちはかわです。
アドベントカレンダー25記事目になるはずだったものです。
去年立てた目標を見ながら反省していきたいと思います。
コンテストで賞をとる
コンテストや大会にはいくつか出ました。
その中でも飛行ロボコンの自動操縦部門で２位になれたので達成ですかね。
勉学に対して意識を高め、理解力UP
耳が痛い話ですね。
言い訳をすると今年は去年より忙しかった気がします。
もっと勉強に精進すべきですね。
専門科目が少しわからない部分があるので勉強したいと思います。
良い、やってみたいことはすぐ行動する
行動しました。
むしろやりすぎてきつかったので、
自分のペースで挑戦していきたいと思います。
インターンも数社行かせていただきました。
勉強会にも行かせていただきました。
現在もプロジェクトに入って作らせていただいてます。
今年は今までよりも充実していたと思います。
しかし、身になったかと言われると微妙な感じがしています。
来年は今まで体験したことを身につける。
自分の能力を高めていきます。
感謝を忘れない
う〜ん
う〜ん
もっともっと日々感謝していきます。
こんな感じですね
いろいろなことに挑戦したのはいいものの、
どれも中途半端になってしまったという感じです。
来年は自分のinputとoutputを意識して行動していきたいと思います。
来年の目標
- 一年で技術系の記事１００個
- わからないことはすぐ調べる、行動する
- 自分が作りたいと思ったものはすぐ作成
- 感謝の気持ちを忘れずに
以上を目標として日々精進していきたいと思います
今年自分に関わってくださった方全てに
この場を借りて感謝の気持ちを伝えさせていただきます。
ありがとうございました。
来年もよろしくお願いします。
余談
去年のpokemon Go の図鑑
今年のpokemon Go の図鑑
たくさん捕まえました。
来年も捕まえていきます
リーダブルコードを読む part3
こんにちはかわです。
アドベントカレンダー１８記事目書いていきます。
前回の続きです。
3章 誤解されない名前
名前が「他の意味と間違えられることはないだろうか？」と自問自答する
1 と 2
誤解を招く名前は変更する
例：Clip(text, length)
def Clip(text, length) ・ ・ ・
このままだと
- 最後からlength文字を削除
- 最大length文字まで切り詰める
のかわからない
疑問を抱かせる名前はだめ
max_charsにすると効果的
3 限界値を含めるときはminとmaxを使う
限界値を明確にするため、名前の前に
max_
min_
をつける
4 範囲を指定するときはfirstとlastを使う
範囲を指定する際に「start」「stop」を使うことがあるが、
stopは複数の意味に解釈される事がある。
包含的な範囲（終端を範囲に含める）なら、firstとlastを使う方がいい
5 包含/排他的範囲にはbeginとendを使う
プログラミングの命名規則では、包含/排他的範囲にbegin endをよく使う
endは少し曖昧だが、英語にはこれに置き換わる語がない（らしい）
beginとendを使うことが最善であるらしい
6 ブール値の名前
ブール値の変数やブール値を返す関数の名前を選ぶ際は、
true falseを明確にすべし
trueかfalseのどちらが正しいかをそれとなくにおわせる必要がある
is や hasを使いブール値だとわかるようにする
否定形は避ける
7 ユーザの期待に合わせる
ユーザが先入観を持っているために誤解を招くことがあるため、
誤解されない名前に変更する必要がある。
例としてget*()をあげると、
コストが低いものだという先入観がある（らしい）。
もしコストが高いのであればこれを明示される名前に変えるべき。
8 例：複数の名前を検討する
名前を決めるときは、複数の候補を検討すべし
