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
誰のためのコメント? / comments-for-whom
Search
yuki
January 09, 2025
Programming
0
110
誰のためのコメント? / comments-for-whom
【ペチオブ】2025年 新年会 書き初め LT
というイベントで発表したスライドです。
https://phper-oop.connpass.com/event/339339/
yuki
January 09, 2025
Tweet
Share
More Decks by yuki
See All by yuki
今年の抱負 2024/Aspirations for 2024
yyykms123
0
190
Vercel Ship まとめ「2023/5/1-5」
yyykms123
0
170
プロジェクト管理で失敗したこと
yyykms123
0
50
脱初心者のための GitHub Actions
yyykms123
0
320
プロジェクトをリリースするまでのプロセス
yyykms123
0
45
実務で使えるGitコマンド
yyykms123
4
1.2k
過去の自分へ送るLT!
yyykms123
0
94
Other Decks in Programming
See All in Programming
Mastering Event Sourcing: Your Parents Holidayed in Yugoslavia
super_marek
0
120
AI時代の脳疲弊と向き合う ~言語学としてのPHP~
sakuraikotone
1
1.6k
安いハードウェアでVulkan
fadis
1
820
それはエンジニアリングの糧である:AI開発のためにAIのOSSを開発する現場より / It serves as fuel for engineering: insights from the field of developing open-source AI for AI development.
nrslib
1
610
Xdebug と IDE による デバッグ実行の仕組みを見る / Exploring-How-Debugging-Works-with-Xdebug-and-an-IDE
shin1x1
0
220
Coding at the Speed of Thought: The New Era of Symfony Docker
dunglas
0
1.6k
我々はなぜ「層」を分けるのか〜「関心の分離」と「抽象化」で手に入れる変更に強いシンプルな設計〜 #phperkaigi / PHPerKaigi 2026
shogogg
2
630
Redox OS でのネームスペース管理と chroot の実現
isanethen
0
460
AI時代のシステム設計:ドメインモデルで変更しやすさを守る設計戦略
masuda220
PRO
6
1.1k
Vuetify 3 → 4 何が変わった?差分と移行ポイント10分まとめ
koukimiura
0
210
GoのDB アクセスにおける 「型安全」と「柔軟性」の両立 - Bob という選択肢
tak848
0
280
OTP を自動で入力する裏技
megabitsenmzq
0
130
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
110k
Making the Leap to Tech Lead
cromwellryan
135
9.8k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
680
Marketing to machines
jonoalderson
1
5.1k
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
240
KATA
mclloyd
PRO
35
15k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4k
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
230
The #1 spot is gone: here's how to win anyway
tamaranovitovic
2
1k
Bash Introduction
62gerente
615
210k
Transcript
誰のためのコメント? 【ペチオブ】2025年 新年会 書き初めLT 2025.01.09 / Yukimasa Ikeda
目次 1. コメントがないコード 2. 過剰なコメント 3. 意図が伝わらないコメント 4. 理想のコメント 2
1. コメントがないコード function a() { execute(); } 「何をする関数か全く分からない…」 このコードを書いた本人に3年後に聞いても「たぶん緊急対応だった」と返される かも。
コメントがないコードの問題 チームで開発している場合、他のメンバーがコードの意図を理解できない。 自分自身でも時間が経つと記憶が曖昧になる。 3
2. 過剰なコメント 実況中継のようなコメントは、逆にノイズになります。 // ループ処理を開始します for (let i = 0;
i < items.length; i++) { process(items[i]); } 「見れば分かる!」と思わずツッコミたくなる。 コメントを書くこと自体が目的になっているケース。 過剰なコメントの問題 コードが変わってもコメントが更新されず矛盾が生じる。 コメントが増えるほど、意図を探すのが困難になる。 4
3. 意図が伝わらないコメント よくある例: 「TODO: 後で直す」 // TODO: 後で直す const result
= doSomething(); なぜ後で直す必要があるのか? どんな状況を想定しているのか? 意図が伝わらないコメントの問題 他人や未来の自分が見ても、何をしたかったのか分からない。 修正のタイミングや優先度が曖昧になる。 5
4. 理想のコメント コメントを書く際は、以下のポイントを押さえるべきです。 1. 目的を説明する: 「この処理が必要な理由は何か?」を明確にする。 2. 意図を明確にする: 「この方法を選んだ背景は何か?」を伝える。 3.
背景を書く: 設計のトレードオフや、特定の仕様に対応した経緯などを補足する。 理想のコメントの例 // ユーザー一覧を取得する際にページネーションを行うため // クエリにlimitとoffsetを追加しています const users = fetchUsers({ limit: 10, offset: 20 }); 6
まとめ コメントは未来の自分や他人に向けて書く。 ただし、コード自体が意図を伝えられるなら、不要なコメントは書かない。 コメントの量より、質が重要。 7
書き初め 8