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
89
リーダブルコード 輪読会 1~3章
社内の2年目エンジニアを中心に行ったリーダブルコード輪読会の1~3章のまとめです
佐々木千奈
June 09, 2023
Tweet
Share
Other Decks in Technology
See All in Technology
スクラムに出会って「できた」を実感できるようになってきた話 / Scrum makes me feel like I can do it
yayoi_dd
2
110
Google Cloudを組織(企業)で運用する時のベストプラクティス × 健康の環境分離戦略 #まるクラ勉強会
yasumuusan
0
150
AWS Observability 関連最新アップデート
o11yfes2023
0
100
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
0
2k
5分で分かる(かもしれない) Vector engine for OpenSearch Serverless
tsukuboshi
1
380
TDD - Test Driven Drupal
opdavies
0
3k
中年男性がメインフレームから クラウドへキャリアシフトしてみた
uechishingo
1
460
ハードウェアを動かすTypeScriptの世界
9wick
3
1.2k
本当のガバクラ基礎
toru_kubota
0
310
エムスリーマルチデバイスチーム紹介資料 / Introduction of M3 Multi Device Team
m3_engineering
0
100
IaCからAWSに入門した初心者が CloudFormationを通して考えた「AWS操作」の使い分け
maimyyym
3
670
RailsConf 2024 Keynote "Startups on Rails in 2024"
irinanazarova
0
730
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
398
65k
From Idea to $5000 a Month in 5 Months
shpigford
377
45k
Robots, Beer and Maslow
schacon
PRO
155
8k
Side Projects
sachag
451
41k
Making Projects Easy
brettharned
109
5.5k
In The Pink: A Labor of Love
frogandcode
138
21k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
81
44k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
12
1.1k
The Straight Up "How To Draw Better" Workshop
denniskardys
228
130k
GraphQLとの向き合い方2022年版
quramy
33
12k
A designer walks into a library…
pauljervisheath
201
23k
Building Your Own Lightsaber
phodgson
100
5.7k
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() には軽量なメソッドが期待されている。
複数の名前を検討する • 自分で名前を決定する前に「本当に大丈夫か?」と問う。そして、誤 解されない名前かどうかを想像してから、名前を決定する
誤解されないような名前をつける。 批判的になって考える。