前回 の続きから行こうと思いますー
4章 美しさ
4章は完全にコードの見た目に関する内容です
メソッドを使ったコードの整列化
4章は割と自分は普段意識していたりフォーマットかけると解決するものが多かったですが、これは今までになかった視点なので今後も意識していきたいです。
コードの1行が長くなりすぎるせいで、同じ処理をしているけど煩雑なコードの見た目になる時があると思うのですがそこを関数に切り出して見た目を整えるという方法が出ていました。この観点で関数を切り出すことはなかったので今後やれる時があったらやってみようと思います。
一貫性のある並び
フィールドの多い構造体があって、その生成の時にフィールド全部宣言しているかわからんくなって定義まで飛んだことってみなさんないですかね？
僕は割とあるのですが（エディタは補完してくれるけど全部宣言したかは教えてくれないので)、フィールド名の順序に規則を持たせるといいなーと思いました。
個人的にはアルファベット順が普遍的でいいなーと思うのですが、DBのkeyなどは一番上に置きたい気持ちがあるし、人に関するものなら Name とかは上の方に置きたい気持ちがあるのでいい感じに取り入れたいです。
# 5章 コメントすべきことを知る
どんなことをコメントすべきかについて書いてある。この章にあることは割と自分でも意識できてたし、チームのコード規約にもあったりするものが多かったのでそんなになかった。
定数にコメントをつける
定数にコメントつけた記憶があまりなかったので意識してみたい。pathとかの定数は別にいらないけど、閾値とかの定数を用意する場合その値の背景を書いてみるのが良さそう。
自分の頭に浮かんだことをとりあえずコメントする
これはコードを読みやすくするという観点ではないけれど、自分がコード書いててこのパターンまずいな、けど実装どうやってやろうとか思った時にとりあえずコメントしておいて後々その注意点を忘れないようにするとかって使い方ができそう。仮に対応しなくなったとしたらそれは残しておくべき。
6章 コメントは正確で簡潔に
コメントの内容についての章です
複数のものを指す可能性がある指示語は使わない
これは今まで普通に使っちゃってた気がする。言われてみると自分は指示語の内容がわかっているけどめっちゃ齟齬が起きそうなポイントである。今後はコメントで複数の理解ができる指示後は使わないようにする。
コメントに入出力の実例を使う
これもやったことがなかった。言葉で表現すると冗長でわかりにくくなるものは、エッジケースの例を使って説明すると読む側も安心して挙動がわかりそう。実践する。
今日はこの辺にしとこうと思います。