2021年の目標「アウトプット100本」に向けたアウトプット活動として、現在エンジニアにおすすめの書籍として有名な「リーダブルコード」を読んでいるので、個人的に気になったところをピックアップしていきます。

読みやすさの重要さ​

エンジニアたるもの、コーディングする際は読みやすさや理解のしやすさを重視しなければいけない。

今は理解できても、数ヶ月放置して見直したときに理解できるだろうか。
プロジェクトに新メンバーが配属されたとき、その人は何の説明もなく理解できるだろうか。

「理解する」というのは、変更を加えたりバグを見つけたりできる

そんなコードを書けるようになりたい。

し、読めるようにもなりたい。

よくある例として以下のようなものがある。

return a == b ? "同じ値" : "違う値"

三項演算子だと一行でまとまってコードは簡潔になる。

下のif文は同じ結果になるが、場合によってはこちらの方が読み手は安心する場合がある。

if a == b {
  return "Same Value"
} else {
  return "Other Value"
}

「簡潔」と「安心」はどちらが大切なことなんだろう？

コード量が減れば読む箇所も減るので理解しやすさも増えるだろうが、何でもかんでも減らすのが正解とも限らない。

コード量 < 理解のしやすさ

これを重視してコーディングをしていく必要がある。

命名について

よく関数で見られる命名で、自分もやりがちなやつ

// ×： getが具体的にどこから取得するかが不明
func getHoge() -> Int

// ○： インターネットから取得する場合
func fetchHoge() -> Int

データをどこから取得するかで表現を変えるだけで、どこから取得するのかが想起できる。

これは確かにってなった。

また、単位を変数名にするというのはあまり考えたことがなかったので感心した。

//　_msをつけることで単位がミリ秒とわかる
var start_ms = (new Date()).getTime() 

ブール値の変数、ブール値を返す関数はtrueとfalseを明確に表現できるようにしなければいけない。

これは普段から意識していた。

hogeButton.isEnabled = isEnabled
hugaView.isHidden = shouldHidden // or isHiddenとか

piyoView.isHidden = !shouldShow // これは微妙

Swiftで普段書く時は上記のような記述をすることはあって、shouldHiddenとshouldShowが混じるとわからなくなるみたいな経験があったので😅

コードのぱっと見の美しさ

ブロックで揃ってたり、適切な箇所で空行があったりするだけでも違う。

Xcodeを使う自分がよくする魔法のコマンドは

command + A → control + I

コードを全選択して、整備する。

関数を使う時の使い方の違いは気になった

func addData(to a: String, b: String) {
}

// 流派1
addData(to: hoge, 
        b: huga)

// 流派2
addData(
    to: hoge, 
    b: huga
    )        

関数名と引数はほぼ適当だが、個人的には流派1。

引数ラベルにto / from / withとか前置詞が付いている時がよくあるかなと思うが、こういうときに関数名を読んでそのまま視線が右に行ってスムーズに読めるから。

流派2の意見として聞いたことあるのは、引数が一つずつ改行されてみやすい。というものでこれも一理あるので、チームでの規約に沿った方が良いとは思う。

皆さんはどうでしょうか。

コメントの残し方

コードからすぐにわかることをコメントに書かない

めっちゃやるわこれ。

過去に書いたやつ。。すまん

/// イテレーターを作成
func createIterator() -> Iterator

自分の考えを記録する

これ地味に重要だと思った。

プログラミングをとりあえず実行してみるのと同じ感覚で、とりあえず書いてみて、自分がどういう意図でそのコーディングをしたのかを書き残す。

そのコメントを見直してより良いコメントにしていくとよりリーダブルになったいくのだなと。

読みやすいコード = 良いコード + 良いコメント

コメント気をつけよ。

代名詞に注意。

例にあったやつ

// データをキャッシュに入れる。ただし、先にそのサイズをチェックする。

「その」が「データ」、「キャッシュ」のどちらを指すかで意味が変わってくるというもの。

// データが十分に小さければ、それをキャッシュに入れる。

模範解答が納得できた。

気付かぬうちに、「それ(it)」を使ってるような気がするから意識してみよう。

てか、これに関しては普段のメッセージでのやりとりでも使えるな笑

*
*
*

ひとまずは見た目の部分についてサラッとみました。

これ以外にも手厚く参考書籍では書かれているので気になる人は読んでみると良いかと。

コードも人間も、見た目は重要な要素なんだなぁ〜。

普段からの心がけ次第で得をすれば損をすることが共通してる。

また一つ悟った夜中の2時前でした。

おやすみなさい。