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
リーダブルコード 輪読会 1~3章
Search
佐々木千奈
June 09, 2023
Technology
0
150
リーダブルコード 輪読会 1~3章
社内の2年目エンジニアを中心に行ったリーダブルコード輪読会の1~3章のまとめです
佐々木千奈
June 09, 2023
Tweet
Share
More Decks by 佐々木千奈
See All by 佐々木千奈
Grafanaのvariables機能について
tiina
0
100
Other Decks in Technology
See All in Technology
RevOpsへ至る道 データ活用による事業革新への挑戦 / path-to-revops
pei0804
2
580
CNAPPから考えるAWSガバナンスの実践と最適化
yuobayashi
5
540
デザインシステムを始めるために取り組んだこと - TechTrain x ゆめみ ここを意識してほしい!リファクタリング勉強会
kajitack
2
290
20250125_Agent for Amazon Bedrock試してみた
riz3f7
2
110
dbtを中心にして組織のアジリティとガバナンスのトレードオンを考えてみた
gappy50
2
410
Site Reliability Engineering on Kubernetes
nwiizo
6
3.9k
バクラクの組織とアーキテクチャ(要約)2025/01版
shkomine
6
650
コスト削減と精度維持を両立!類似画像検索システムの内製化成功事例
shutotakahashi
0
350
プロダクト開発、インフラ、コーポレート、そしてAIとの共通言語としての Terraform / Terraform as a Common Language for Product Development, Infrastructure, Corporate Engineering, and AI
yuyatakeyama
6
1.4k
サーバレスの未来〜The Key to Simplifying Everything〜
kawaji_scratch
2
340
panicを深ぼってみる
kworkdev
PRO
1
120
20250129 Findy_テスト高活用化
dshirae
0
180
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
66
11k
Facilitating Awesome Meetings
lara
51
6.2k
The Power of CSS Pseudo Elements
geoffreycrofte
74
5.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.2k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Code Reviewing Like a Champion
maltzj
521
39k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
KATA
mclloyd
29
14k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
Transcript
理解しやすいコード / 名前について 佐々木千奈
リーダブルコードの全体像 • 第0部 ◦ はじめに ◦ 1章 理解しやすいコード • 第1部
表面上の改善 ◦ 2章 名前に情報を詰め込む ◦ 3章 誤解されない名前 ◦ 4章 美しさ ◦ 5章 コメントするべきことを知る ◦ 6章 コメントは正確で簡潔に • 第2部 ループとロジックの単純化 ◦ 7章 制御フローを読みやすくする ◦ 8章 巨大な式を分割する ◦ 9章 変数と読みやすさ • 第3部 コードの再構成 ◦ 10章 無関係の下位問題を抽出する ◦ 11章 一度に1つのことを ◦ 12章 コードに思いを込める ◦ 13章 短いコードを書く • 第4部 選抜テーマ ◦ 14章 テストと読みやすさ ◦ 15章 「分/時間カウンタ」を設計・実装する • 付録 • 解説
1章 理解しやすいコード
キー1:コードは理解しやすくなければならない • 筆者が集めてきた「ひどいコード」を見て、なぜそのコードがひど いのか、それを改善するためにはどんな原則や技法が使えるの かと調べてみたところ、コードは理解しやすくなければならないと いうたった1つの原則にたどり着いた。
優れたコードって何? • 何でしょう
キー2:コードは他の人が最短時間で理解できるように書かな ければならない • コードは他の人が最短時間で理解できるように書かなければならな い、これが筆者がたどり着いた読みやすさの基準。 • この本ではこれを「読みやすさの基本定理」としている。 • 「他の人」に読ませないコードだとしても、「他の人」というのは6か月 後の自分自身かも。
2章 名前に情報を埋め込む
名前に情報を詰め込むTips • 明確な単語を選ぶ • tmp や retval などの汎用的な名前を避ける • 抽象的でなく、具体的な名前を使って、物事を詳細に説明する
• 変数名に大切な情報を追加する • スコープの大きな変数には長い名前を着けてOK • 大文字やアンダースコアなどに意味を含める
明確な単語を選ぶ • getPageという曖昧な単語より、fetchPage()やDownloadPage() な どの明確な単語の方が良い
tmp や retval などの汎用的な名前を避ける • 関数の内部でもtmpやretvalなどの空虚な名前ではなく、その物の 値についてや変数の目的を表した名前をつける • 例: 変数を2乗の足し算の結果の格納に使うなら、retvalよりも
sum_squaresのほうが◎
抽象的でなく、具体的な名前を使って、物事を詳細に説明する • Googleでは使ってはいけないコンストラクタを使えなくするためのマ クロを、DISALLOW_EVIL_CONSTRUCTORS(♰許されざるコン ストラクタ♰)と名付けていた。 これでは、許可しないコンストラクタが具体的に分からないので、コ ピーとアサインを許可しないのであれば、 DISALLOW_COPY_AND_ASSIGNのように許可されないコンスト ラクタを示すために具体的に書く。
変数名に大切な情報を追加する • ms,mbなどの単位や、セキュリティに気を付ける必要がある plaintext_passwordなど、重要な属性は変数名に記録する
スコープの大きな変数には長い名前をつける • 名前に必要な情報を追加していく中で、名前が長くなってしまっても タブで補完できるので躊躇しない。 • 短いスコープでは短い名前をつけてもOK
大文字やアンダースコアなどに意味を含める • クラス名はCamelCase、変数名はlower_separatedなど、名前のフォーマットに意 味を持たせる
変数や関数などは名前を見ただけで情報 が分かるように命名する!!!
3章 誤解されない名前
誤解されない名前をつけるためのTips • filiter • Clip • minとmax • 範囲にはfirstとlast •
包括 / 排他的範囲にはbeginとend • ブール値の名前 • ユーザの期待に合わせる • 複数の名前を検討する
filter • データベースの問い合わせ結果を処理するコードを書いているとし て、filterという名前より、選択するならselect()、除外するなら exclude()とするなどの工夫をする
Clip(text,length) • テキストを切り取って「...」をつける関数で、上記のままだとlengthが 最後から切り取る文字数なのか最大文字数なのか分からないの で、max_charsなどの名前にする
限界値にはminとmax • 限界値には、TOO_BIG_LIMITなどより、minとmaxを使う
包括的範囲の指定にはfirstとlast • start,stopだとどこで終了するのかわからないので、包括的範囲(最 初から最後までを含む)を表す際はfirstとlastを使う
包含 / 排他的範囲にはbeginとend • 包含 / 排他的範囲(最初は含むが、最後は含まない場合)はbegin とendを使う
ブール値の名前はtrueとfalseの意味を明確にする • read_passwordだと曖昧、need_passwordや user_is_authenticatedなどの名前にしたほうが良い。 • ×disable_ssl ◎use_ssl のほうがいい。
ユーザーの期待に合わせる • 一般的な関数名や変数名の使い方に従う。 • 例えば、get() や size() には軽量なメソッドが期待されている。
複数の名前を検討する • 自分で名前を決定する前に「本当に大丈夫か?」と問う。そして、誤 解されない名前かどうかを想像してから、名前を決定する
誤解されないような名前をつける。 批判的になって考える。