良いコメントが良い設計を導く

要旨 コメントを適切に記述することは、特にインターフェイス（クラスやメソッド）において重要です。これにより、直感性が高まり、抽象化が十分に行われているかを確認する手助けになります。そのため、コメントはソフトウェア設計プロセスの重要な一部と位置づけられます。 2種類のコメントタイプ まず、コメントを2種類に分類します。 1️⃣ コードをより詳細化するコメント(lower-level comment) 2️⃣ コードをより抽象化するコメント(higher-level comment) どちらも必要なコメントとしつつ、本書では後者のコメントをより重視しています。 1️⃣ コードを詳細化するコメント(lower-level comment) 変数名などに残すタイプのコメントで、宣言した対象の単位や境界値、null許容などの詳細を明示することで、コードの正確性を高めます。こちらのタイプのコメントも必

[dotneet]

なんなら良いコメントで実装が完了する時代。Copilot強し。

[turanukimaru]

私ならPaddingのコメントには「枠と文字の隙間が無くて読みにくいので隙間を開ける。4なのは感覚的なもので特に意味はない」と書くかな。何をしてるのかではなく何のためにそんなもんがあるのかが大事だ。

[r-west]

命名では不足の情報がちゃんと書いてあると読むの楽なのは理解。ただ、このレベルのコメント書ける人は多くないのと、結局詳細仕様書なので実際のコードとの乖離がそれなりに生じていって古文書扱いになりそうな気も

[diveintounlimit]

Copilotはたしかにコメント書くけど、基本的に「// AをBする A->B」みたいなコメント多くない？（基本消してる

[pmint]

この詳細化するコメントは良くない。せめて変数名に書かないと。/ 抽象的に書くなら、バージョンアップされても変わらない点を書かないといけなくて、それは設計。実装時に考えては遅い。

[opnihc]

"コードを書き始める前に先にコメントを書く「コメントファーストアプローチ」を採用する"→そもそも設計入る前にコメント、関数宣言で骨格作って実装検討するけどcopilotでその後が楽になったね

[nemoba]

TaskManagerは、むしろ抽象が乱暴すぎて逆にコメントが無きゃいけない悪い例になってる。ではなく"タスク排他制御"とかの抽象の話だと思うよ

[tettekete37564]

ドキュメンテーションジェネレーターでドキュメントの共有と管理をするのが当たり前な現代においてコメント不要論って前世紀の遺物でしょ。自分さ定義的に「何をどうする」モノなのかと「なぜそうするのか」は書く

[ledsun]

アルゴリズムの概要はソースコードからも読み取れるけどコメントで説明してあった方が、すっとソースコードが読めていい。嘘や誤解であることもある。作者の誤解に気がつく手がかりにもなる

[masalib]

Copilotで書いているのでコメントがちゃんとしていないとバグる・・・あとで読みにくい場合は消すかな

[moja8]

デザインレシピの出番かも (『プログラミングの基礎』電子版もあるヨ https://www.saiensu.co.jp/search/?isbn=978-4-7819-9932-6&y=2018)

[udukishin]

Copilot使ってるとちゃんとコメント書くとある程度コード書いてくれるから可読性が勝手に上がっていくんだよね

[roshi]

「コメントを書くくらい複雑なら関数に分ける（それをコメントの代用にする）」に遭遇したことある。普通にコメント書いてくれw

[yarumato]

“コメントを書くことに否定的なRobert Martinの著書「Clean Code」への反論。コードを詳細化するコメント(lower-level comment)、抽象化するコメント(higher-level comment)、どちらも必要だが後者をより重視”

[mushus]

悪いコメントに対する良いコメントとはなにか？