1) 概要（役割）
コメントは「プログラム内に残すメモ」で、実行時は無視されます。コードの説明・意図・TODO・ライセンスヘッダなどを残すために使います。
また、エンジン側ではコメントは空白（ホワイトスペース）と同様に扱われ、実行に影響を与えません（解析時に破棄されます）。
2) 文法（よく使う記法）
行コメント（シングルライン）
// ここから行末までがコメント
let x = 5; // 行末にコメントを付ける例ブロックコメント（複数行）
/* 複数行にわたるコメント
説明や著作情報をまとめるのに便利 */
let x = 5;これらはどちらも行頭でも行末でも使えます。
3) ドキュメンテーション用コメント（JSDoc）
ライブラリや公開 API の説明には JSDoc スタイルのコメント（/** ... */）を使うと便利です。ツール（jsdoc）やエディタが @param や @returns 等のタグを解析してドキュメント生成や型ヒント表示に利用できます。
例：
/**
* 与えられた数値を足し合わせる
* @param {number} a - 第1引数
* @param {number} b - 第2引数
* @returns {number} 合計
*/
function add(a, b) {
return a + b;
}/** で始まるブロックが JSDoc の対象です。ツールの仕様やタグ一覧は JSDoc の公式ドキュメントを参照してください。
4) HTML のコメント（<!-- ... -->）との違い
HTML のコメントは <!-- コメント --> です。HTML 内での使い方や制約は HTML 側のルールに従います。<script> 内に書くコメントは JavaScript の記法（// や /* */）が原則です。歴史的に古いブラウザ互換のために HTML コメントでスクリプトを囲うことがあった（教科書的な例）ため混同しがちですが、現在は基本的に不要・推奨されません。
5) よくある注意点（落とし穴）
- ブロックコメントはネストできない
/* ... /* ... */ ... */のように多重の/* */は想定どおり動作せず、最初の*/で閉じられます。コメントの中に別の/* */を入れるとコードが壊れるので注意。ネスト不可は多くの言語で共通の挙動です。 - コメントの放置（古いコメント）
仕様や実装が変わったのにコメントを更新していないと、却って誤解を招きます。コメントはコードと同じくメンテナンス対象と考えてください。 - “コメントアウトしたコード”を残しすぎない
履歴はバージョン管理に任せ、リポジトリに古い実装を残すために大量のコメントアウトを置くのは避けたほうが良いです。 - セキュリティ・機密情報
ブラウザで配信されるクライアントサイドのスクリプトでは、コメントは最終的にユーザーに見られます（ソース閲覧可能）。パスワードやAPIキーなど機密情報をコメント内に残すのは重大なリスクです。
6) 実務的ベストプラクティス（短いチェックリスト）
- 「何をしているか」ではなく 「なぜその実装にしたか」 をコメントする（Why を書く）。
- 公開 API やライブラリは JSDoc で文書化する（自動ドキュメント化、IDE の補完に有効）。 jsdoc.app
- 一時的な作業箇所は
// TODO:/// FIXME:として明記し、タスク管理に連携する。 - Linter（ESLint 等）でコメントに関するルールを設定すると一貫性が保てる。
- 長い説明は README や設計ドキュメントに移し、コード上は短く要点だけ残す。
- 古いコメントやコメントアウトコードは定期的に掃除する（PR レビューでチェック）。
JavaScript | MDN
JavaScript (JS) は軽量でインタープリター型（あるいは実行時コンパイルされる）第一級関数を備えたプログラミング言語です。ウェブページでよく使用されるスクリプト言語として知られ、多くのブラ...
developer.mozilla.org