Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
リーダブルコード 輪読会 1~3章
Search
佐々木千奈
June 09, 2023
Technology
0
220
リーダブルコード 輪読会 1~3章
社内の2年目エンジニアを中心に行ったリーダブルコード輪読会の1~3章のまとめです
佐々木千奈
June 09, 2023
Tweet
Share
More Decks by 佐々木千奈
See All by 佐々木千奈
Grafanaのvariables機能について
tiina
1
590
Other Decks in Technology
See All in Technology
ハッカソンから社内プロダクトへ AIエージェント「ko☆shi」開発で学んだ4つの重要要素
sonoda_mj
6
1.3k
SQLだけでマイグレーションしたい!
makki_d
0
1.2k
IAMユーザーゼロの運用は果たして可能なのか
yama3133
2
520
Kiro を用いたペアプロのススメ
taikis
4
1.4k
Identity Management for Agentic AI 解説
fujie
0
340
ペアーズにおけるAIエージェント 基盤とText to SQLツールの紹介
hisamouna
2
1.3k
コンテキスト情報を活用し個社最適化されたAI Agentを実現する4つのポイント
kworkdev
PRO
1
1.8k
New Relic 1 年生の振り返りと Cloud Cost Intelligence について #NRUG
play_inc
0
160
フィッシュボウルのやり方 / How to do a fishbowl
pauli
2
350
意外と知らない状態遷移テストの世界
nihonbuson
PRO
1
150
S3を正しく理解するための内部構造の読解
nrinetcom
PRO
3
230
[Data & AI Summit '25 Fall] AIでデータ活用を進化させる!Google Cloudで作るデータ活用の未来
kirimaru
0
150
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
0
180
Become a Pro
speakerdeck
PRO
31
5.7k
Reflections from 52 weeks, 52 projects
jeffersonlam
355
21k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
6.7k
Believing is Seeing
oripsolob
0
14
How GitHub (no longer) Works
holman
316
140k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.8k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
310
What does AI have to do with Human Rights?
axbom
PRO
0
1.9k
Designing Powerful Visuals for Engaging Learning
tmiket
0
180
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
320
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() には軽量なメソッドが期待されている。
複数の名前を検討する • 自分で名前を決定する前に「本当に大丈夫か?」と問う。そして、誤 解されない名前かどうかを想像してから、名前を決定する
誤解されないような名前をつける。 批判的になって考える。