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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
yuki
January 09, 2025
Programming
120
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
誰のためのコメント? / comments-for-whom
【ペチオブ】2025年 新年会 書き初め LT
というイベントで発表したスライドです。
https://phper-oop.connpass.com/event/339339/
yuki
January 09, 2025
More Decks by yuki
See All by yuki
今年の抱負 2024/Aspirations for 2024
yyykms123
0
190
Vercel Ship まとめ「2023/5/1-5」
yyykms123
0
180
プロジェクト管理で失敗したこと
yyykms123
0
52
脱初心者のための GitHub Actions
yyykms123
0
330
プロジェクトをリリースするまでのプロセス
yyykms123
0
46
実務で使えるGitコマンド
yyykms123
4
1.2k
過去の自分へ送るLT!
yyykms123
0
98
Other Decks in Programming
See All in Programming
AI駆動開発勉強会 広島支部 第一回勉強会 AI駆動開発概要とワークショップ
hayatoshimiu
0
450
Datadog × OpenTelemetry 入門と実践のあいだ
kn_to_maxpno
1
150
脅威をエンジニアリングの糧にして――現場編 / Turning Threats into Engineering Fuel — Field Edition
nrslib
0
250
Claspは野良GASの夢をみるか
takter00
0
170
並列実装の現場、2ヶ月間実務でAIを使い倒したAIもPCも私も限界が近い
ming_ayami
0
110
GitHub Copilot CLIのいいところ
htkym
2
1.3k
キャリア迷子上等 ─ "ない道"は自分で作ればいい
16bitidol
3
1.7k
oxlintはeslint/typescript-eslintを置き換えられるのか
shomafujita
2
320
運用エージェントは "作る" から "育てる" へ - 記憶と自己進化の3層設計パターン / self-evolving-agents-three-layer-agent-design
gawa
12
3.5k
Spring Security 実践 ─ GraphQL APIで実務に役立つ 認証・認可 を学ぶ
wagyu
0
160
Inside Stream API
skrb
1
650
AIエージェントの隔離技術の徹底比較
kawayu
0
460
Featured
See All Featured
Scaling GitHub
holman
464
140k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
140
Exploring anti-patterns in Rails
aemeredith
3
400
A Modern Web Designer's Workflow
chriscoyier
698
190k
The browser strikes back
jonoalderson
0
1.1k
WCS-LA-2024
lcolladotor
0
620
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
280
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.3k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.2k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
52k
The Invisible Side of Design
smashingmag
302
52k
ラッコキーワード サービス紹介資料
rakko
1
3.6M
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