C++ comments: `//`, `/* */`, and how to comment like a pro

Short answer: // comments out the rest of the line; /* ... */ comments out anything between the markers, even across lines. The compiler throws both away before it even starts — proof below.

#include <iostream>
using namespace std;

// This line comment explains the program. The compiler ignores it.

/* Block comments can span
   as many lines as you need. */

int main() {
    cout << "comments are ignored" << endl;  // trailing comment
    // cout << "this line does not run";
    return 0;
}

The output proves the point: commented lines produce no code, no output, no cost. That makes comments a communication tool for humans — and like all communication, most of it is noise.

The two forms

Form	Extends	Typical use
`// line comment`	to end of line	Explaining one line or one decision — the everyday default
`/* block */`	until the closing `*/`	Temporarily disabling a chunk of code, file-header notes

The trap: block comments don't nest

/*
  Disabling this debug block...
  /* inner comment */    ← the block ENDS here!
  cout << "this is NOT commented out";   // ← surprise, it's live code
*/                        // ← stray */ — syntax error

The first */ closes the block, no matter how many /* opened. This is why debugging-by-block-comment goes wrong in confusing ways. For temporarily disabling code, prefer #if 0 … #endif (which does nest) or just delete it — version control remembers.

What separates good comments from noise

Good: explain WHY, not what. // retry: the API rate-limits bursts tells the next reader something code can't. // add 1 to i tells them what the line already says.
Good: flag intent and trade-offs. // O(n²) but n ≤ 100 here — fine pre-empts a pointless "optimization" PR.
Bad: commented-out code left behind. It rots, it's in the way, and version control already has it if you ever need it back.
Bad: lying comments. A comment that disagrees with the code is worse than no comment — when you change code, update or delete its comment in the same breath.
Conventions worth knowing: // TODO: for planned work, // FIXME: for known breakage, /// doc-comments that tools like Doxygen extract into documentation.

Comments in the wild (interview angle)

"Do comments affect performance?" — no; they're stripped before compilation. Zero runtime cost, tiny compile-time cost.
"Can block comments nest?" — no; the first */ wins (see trap above). A surprisingly common screening question.
"What are doc comments?" — ///-style annotations that documentation generators turn into reference docs; standard practice for public APIs.
"How would you review a 300-line diff with no comments?" — the real question behind the question: does the code explain its why? Names can carry a lot; comments carry what names can't.

Practice

Run the example above, then comment out the working cout and un-comment the disabled one — flip the program's output without changing any real code.
Break it: put /* before return 0; and don't close it — read the compiler's complaint about unexpected end of file (a cousin of the errors in our common errors guide).
Go solve Sum from 1 to N and write exactly one comment: the "why" of your loop bound.

Related: the Hello World lesson (where comments first appear), what int main() is, and the while loop explained.