Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
読みやすいコードを書こう
Search
Yutorin
May 16, 2022
Programming
0
980
読みやすいコードを書こう
社内のLT会で発表したスライドです。
Yutorin
May 16, 2022
Tweet
Share
More Decks by Yutorin
See All by Yutorin
新卒でサービス立ち上げから Hasuraを使って3年経った振り返り
yutorin
0
680
Other Decks in Programming
See All in Programming
rage against annotate_predecessor
junk0612
0
170
AI Coding Agentのセキュリティリスク:PRの自己承認とメルカリの対策
s3h
0
230
デザイナーが Androidエンジニアに 挑戦してみた
874wokiite
0
540
Android端末で実現するオンデバイスLLM 2025
masayukisuda
1
170
JSONataを使ってみよう Step Functionsが楽しくなる実践テクニック #devio2025
dafujii
1
590
はじめてのMaterial3 Expressive
ym223
2
880
Android 16 × Jetpack Composeで縦書きテキストエディタを作ろう / Vertical Text Editor with Compose on Android 16
cc4966
2
260
FindyにおけるTakumi活用と脆弱性管理のこれから
rvirus0817
0
520
Namespace and Its Future
tagomoris
6
700
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
4
2.9k
より安全で効率的な Go コードへ: Protocol Buffers Opaque API の導入
shwatanap
1
340
複雑なドメインに挑む.pdf
yukisakai1225
5
1.2k
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
The Pragmatic Product Professional
lauravandoore
36
6.9k
Agile that works and the tools we love
rasmusluckow
330
21k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
GraphQLとの向き合い方2022年版
quramy
49
14k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
920
A Tale of Four Properties
chriscoyier
160
23k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.9k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Bash Introduction
62gerente
615
210k
Transcript
読みやすいコードを書こう 2022/05/13 - Yutorin
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