[day: 3]小さな効率化とリーダブルコード

小さな効率化とリーダブルコード

はじめに

2020/4/1にエンジニアになりました。
scala/Play、TypeScript/Angular
ほぼ日記みたいな内容です。
毎日の学習のアウトプットが目的です。

小さな効率化

小さいですが、積み重なると大きい効率化をしました。
それはHotKeyを利用してiTerm2を開くことです。
今までは別の画面からiTerm2を開くときにはcommand + tabを使って切り替えてました。
キーボードのホームポジションから大きく左手がずれてしまうのと、タブでの選択を間違えてしまうと大きく時間をロスしてしまいます。
ショートカットでHotKeyを設定すると一瞬で今いる画面の上に被さる形でiTerm2を表示できるので、調べ物から開発に切り替える際の動きが格段に早くなりました。
自分はoption + enterで設定しています。
おすすめなので皆さんも試して見てはいかがでしょうか。

参考にした記事
iTerm2のおすすめ設定〜ターミナル作業を効率化する〜

リーダブルコード

リーダブルコードを読みましたので、簡単にまとめたいと思います。
リーダブルコード――より良いコードを書くためのシンプルで実践的なテクニック

1章 理解しやすいコード

• コードは他人にとって理解しやすく書く
• コードは他人が最短時間で理解できるように書く
• 理解する時間が短い > コードが短い
• このコードは見やすいか確認する

2章 名前位に情報を詰め込む

• 名前に情報を詰め込む
• 名前は小さなコメントである
• 明確な単語を選ぶ
  • 適格な意味を持つ単語を選択する
  • シソーラスで検索して調べる
  • 気取った言い回しよりも正確で明確な単語を選ぶ
• 汎用的な名前を避ける 例)tmpやretval
  • 情報の保存期間が一瞬であれば汎用的で良い
• 抽象的な名前よりも具体的な名前を使う
  • 変数名が抽象的だと使用者によって解釈が異なる
    • 何をするのか明確にわかる名前をつける
• 名前に情報を追加する
  • 絶対に伝えたい情報は名前に入れる
  • 単位など
• 名前の長さを決める
  • 名前は長すぎないようにする
  • スコープの範囲が短い場合には短くても良い
    • 理解しにくい省略形の名前はつけない
• 名前のフォーマットで情報を伝える
  • クラスや変数で使用するフォーマットを変えると読みやすくなる
  • プロジェクトでの一貫性が大事

3章 誤解されない名前

• 他人が違う意味に誤解しないか確認する
• 否定形を避ける

4章 美しさ

• 優れたコードは目に優しいものである
• 似ているコードは似ているように書く
• インデントを揃えて縦の線を真っ直ぐにする
• コードを段落に落とし込む

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

• コメントの目的は書き手の意図を読み手に知らせることである
• コメントを読んだ方が理解がはやか？
• 優れたコード > ひどいコード+コメント
• 変数名を変えることでコメントが不要にならないか考える
• プログラマーが使う典型的な意味 -TODO:後で手をつける
  • FIXME:既知の不具合があるコード
  • HACK:あまりキレイじゃない解決法
  • XXX:危険！大きな問題がある
• 質問されそうな箇所を考える
  • 新しく入ったメンバーが理解に時間がかかる箇所などを考える
• 巨大な関数の流れをコメントで把握できるようにする

6章 コメントは正確で簡潔に

• コメントは簡潔に
• 曖昧な代名詞を避ける
• 小さな領域に情報を詰め込む

7章 制御フローを読みやすくする

• 条件式の引数の並び順
  • 左；変化する、右；変化しない
• if文の記述
  • 肯定系を優先して使う
  • 単純な処理を先に書く
  • 目立たせたい処理を先に書く
• ネストを浅くする

8章 巨大な式を分解する

• 説明変数:式の意味を説明する
• 要約変数:式の内容を小さく分割できる、その式の内容を要約している

9章 変数と読みやすさ

• 不要な変数を削除する
  • 変数が減るとコードは簡潔になる
  • 本当にその変数が必要か確認する
• 変数のコードを縮める
  • グローバルな変数は削除する

10章 無関係な下位問題を抽出する

• 汎用的なコードを作成する
• 高レベルの解決に集中する
  • 下位問題は分解して抽出する

11章 1度に一つのことを

• 2つ以上のことを行っているコードは分解する
• ヘルパーメソッドを利用する
  • ヘルパーメソッドとは他の関数に依存することなくある特定の処理を行うメソッド

12章 コードに思いを込める

• 簡単にわかりやすく説明できなければ理解したとは言えない
  • おばあちゃんにも理解できるように説明できますか？
  • コードの動作を同僚に簡単な言葉で説明してみる
  • 説明の中で使用したキーワードやフレーズに注目する
  • その説明に合わせてコードを書く

13章 短いコードを書く

• ライブラリが何を提供しているのかを知る
  • 普段使用しているライブラリの提供しているものを定期的にじっくり見てみる
  • 標準ライブラリで解決できる問題があることがある
• 今書いているそれらのコードは本当に必要か？
• 1日にエンジニアが出荷するコードは10行である
• 不要な機能はプロダクトから削除する
  • メモリの消費を抑える
• 過剰な機能はもたせない
• 最も簡単に問題を解決する方法を考える

最後に

• 実際にやる
• 当たり前にする
• コードでつたる

毎日投稿について

• 完全な自己満足
• アウトプットの習慣づけ
• インプットした内容の記憶の定着を促進
• 継続 > クオリティ
• 昨日の自分より成長している実感を得る