Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

A7048be18b1c2e712e5b564b1adb1f7e?s=128

Yutorin

May 16, 2022
Tweet

Other Decks in Programming

Transcript

  1. 読みやすいコードを書こう 2022/05/13 - Yutorin

  2. 2 自己紹介 Yutorin 日本語が下手です

  3. ・読みにくいコードがあると、 読みたくないし時間もかかる! 3 読みやすいコード書いてる? reference: https://qiita.com/shimataro999/items/ef6cd838d56f1fe87015

  4. ・レビューしたくなくなる ・治安が悪くなる ・ = 読みにくいコードが再生産される ・なにより次の日自分で読めない! 4 自分が読めればええやん?

  5. いくつか抜粋して紹介します ・何が良いコードなのか? ・良くなるコードの書き方 ・コメントについて 5 そのために古事記を読め

  6. ・良いコードは1行で凄いことをすることじゃなくて、  理解しやすいかどうか ・コードは他の人が最短時間で理解出来るようにする ・そのためにコメントをつけることも大事 ・常に「このコードは理解しやすいだろうか?」と頭の中の誰かに問い 続ける 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. 7日より前のファイルは消えているためその日付以前は filter()している とか。 10 コメントをすべきこと

  11. ・コードからすぐわかることをコメントに書かない ・コメントをつけるよりも変数名を変える方がいい場合もある 11 コメントすべきではないこと

  12. ・コメント書いたほうが良いかな?と思った場合はとりあえず書こう ・後から丁寧に書き直してみたり、今まで振り返ってきたこと(改善 点を見つけてより良くする)をやってみる。 ・// ヤバいかも。重複してたら壊れちゃう。 →// 注意:この関数は重複を処理できません(難しいので) 12 とりあえず書いてみよう

  13. ・読む人の気持ちになろう ・コードを通して他の人と対話するように ・英語脳になろう ・英語が伝わってるかどうか考えることで良いコードになる・・かも? ・こだわりを持とう 13 要は...

  14. 14 読んでみてね!おわり!

  15. 15