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
59
誰のためのコメント? / 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
140
Vercel Ship まとめ「2023/5/1-5」
yyykms123
0
110
プロジェクト管理で失敗したこと
yyykms123
0
37
脱初心者のための GitHub Actions
yyykms123
0
310
プロジェクトをリリースするまでのプロセス
yyykms123
0
37
実務で使えるGitコマンド
yyykms123
4
1.1k
過去の自分へ送るLT!
yyykms123
0
83
Other Decks in Programming
See All in Programming
情報漏洩させないための設計
kubotak
5
1.2k
KubeCon NA 2024の全DB関連セッションを紹介
nnaka2992
0
110
テストコードのガイドライン 〜作成から運用まで〜
riku929hr
6
1.3k
PHPUnitしか使ってこなかった 一般PHPerがPestに乗り換えた実録
mashirou1234
0
390
コンテナをたくさん詰め込んだシステムとランタイムの変化
makihiro
1
180
どうして手を動かすよりもチーム内のコードレビューを優先するべきなのか
okashoi
3
820
短期間での新規プロダクト開発における「コスパの良い」Goのテスト戦略」 / kamakura.go
n3xem
2
210
数十万行のプロジェクトを Scala 2から3に完全移行した
xuwei_k
0
950
テストコード書いてみませんか?
onopon
2
290
PHPカンファレンス 2024|共創を加速するための若手の技術挑戦
weddingpark
0
120
AppRouterを用いた大規模サービス開発におけるディレクトリ構成の変遷と問題点
eiganken
1
410
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
2
790
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.7k
Practical Orchestrator
shlominoach
186
10k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Building Adaptive Systems
keathley
38
2.3k
The Language of Interfaces
destraynor
155
24k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
940
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.8k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
171
50k
YesSQL, Process and Tooling at Scale
rocio
170
14k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
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