読みやすいコードを書こう

社内のLT会で発表したスライドです。

Transcript

1. 読みやすいコードを書こう 2022/05/13 - Yutorin
2. 2 自己紹介 Yutorin 日本語が下手です
3. ・読みにくいコードがあると、 読みたくないし時間もかかる！ 3 読みやすいコード書いてる？ reference: https://qiita.com/shimataro999/items/ef6cd838d56f1fe87015
4. ・レビューしたくなくなる ・治安が悪くなる ・ ＝ 読みにくいコードが再生産される ・なにより次の日自分で読めない！ 4 自分が読めればええやん？
5. いくつか抜粋して紹介します ・何が良いコードなのか？ ・良くなるコードの書き方 ・コメントについて 5 そのために古事記を読め
6. ・良いコードは１行で凄いことをすることじゃなくて、 　理解しやすいかどうか ・コードは他の人が最短時間で理解出来るようにする ・そのためにコメントをつけることも大事 ・常に「このコードは理解しやすいだろうか？」と頭の中の誰かに問い 続ける 6 理解しやすいコード
7. ・dataとかsizeとか曖昧な単語ではなく、明確で正確な単語を使おう ・data: property, description, result ・size: height, bytes, weight ・類語辞典を使おう ・get 類義語 ・get synonyms とか検索すると色々でてくる 7 名前に情報を詰め込もう
8. ・変数に入っている情報が名前だけで読み取れないなら、追加したほう がいい ・base64化したchime_idなら encodedChimeId とか、 　　　　base64ChimeIdとか。 ・圧縮したjpg画像なら compressedImage とか compressedJpgとか 8 名前に情報を追加する
9. ・プログラミングの時間のほとんどはコードを読む時間 ・同じようなことをするなら、同じようなものを作ろう 9 一貫性のあるコードを書こう
10. ・コメントの目的は、書き手の意図を読み手に知らせること ・コードを書いているときの自分の考えを記録する ・他の方法がある場合、なんでこの方法を選んだか ・欠陥がある場合はFIXME、やることが残っているならTODOなど ・関数名やコード軽く眺めるだけでは得られない必要な情報 ・e.g. ７日より前のファイルは消えているためその日付以前は filter()している　とか。 10 コメントをすべきこと
11. ・コードからすぐわかることをコメントに書かない ・コメントをつけるよりも変数名を変える方がいい場合もある 11 コメントすべきではないこと
12. ・コメント書いたほうが良いかな？と思った場合はとりあえず書こう ・後から丁寧に書き直してみたり、今まで振り返ってきたこと（改善 点を見つけてより良くする）をやってみる。 ・// ヤバいかも。重複してたら壊れちゃう。 →// 注意：この関数は重複を処理できません（難しいので） 12 とりあえず書いてみよう
13. ・読む人の気持ちになろう ・コードを通して他の人と対話するように ・英語脳になろう ・英語が伝わってるかどうか考えることで良いコードになる・・かも？ ・こだわりを持とう 13 要は...
14. 14 読んでみてね！おわり！
15. 15