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