Comments in C: Syntax, Styles, and Practical Usage

⚠️ The Nested Comment Trap (Read This Before It Bites You)

Here's the gotcha that has confused C programmers for fifty years:multi-line comments cannot be nested.

/*   Trying to explain the outer block...
   /* inner comment attempt */ ← the comment ENDS here!
This text is now CODE. The compiler tries to compile it. 💥*/

Why? The compiler matches/*with thevery next*/it finds — it doesn't count nesting levels. The moment it hits that inner*/, the comment closes, and everything after gets compiled as code, producing errors that baffle beginners.

The safe rule:one/*pairs with the next*/, period. If you need to comment out a block that already contains/* */comments, use single-line comments instead — or better, the preprocessor trick below.

Pro Trick: Commenting Out Code With #if 0

When debugging, you often want to disable a whole chunk of code temporarily. Wrapping it in/* */fails if the chunk contains comments (the nesting trap). The professional solution:

#include <stdio.h>
int main() {
    printf("This runs.\n");
    #if 0 printf("This never compiles.\n");
    /* Even block comments inside are totally fine here */ int broken =;
    // even invalid code is ignored#endif
    printf("Back to normal.\n");
    return 0;
}

#if 0tells the preprocessor "this condition is false — skip everything until#endif." It handles nesting gracefully and flips back on by changing0to1. Old-school, battle-tested, everywhere in real codebases.

When to Comment (and When Not To)

Syntax is easy.Judgmentis the real skill. Here's the framework professionals use:

✅ DO comment...

❌ DON'T comment...

int i = 0;
// declaring i as 0        ← useless, code already says it
i = i + 1;
// adding 1 to i           ← pure noise
printf("Hi\n");
// printing Hi             ← really?

The golden rule:good comments explainwhy; bad comments narratewhat.If the code clearly shows what it does, a comment repeating it just creates a second thing to maintain — and worse, comments can go stale. A comment that says the opposite of what the code does is worse than no comment at all.

[IMAGE 3 — Infographic: "Why vs What" Comment Guide]Design:Two columns — green "WHY ✅" side with good comment examples, red "WHAT ❌" side with narration examples. Headline: "Comment the why, not the what."Alt text:Best practices for comments in C explain why not what with examples

Comments vs Self-Documenting Code

One more professional secret: the best comment is oftenbetter code.

// ❌ check if the year is divisible by 4 but not by 100, unless by 400
if (y % 4 == 0 &&(y % 100 != 0 || y % 400 == 0)) {
    ...
}
// ✅ the name explains it — no comment needed
int isLeapYear =(y % 4 == 0 &&(y % 100 != 0 || y % 400 == 0));
if (isLeapYear) {
    ...
}

Descriptive variable and function names eliminate whole categories of comments. When you feel the urge to write a long comment explaining a confusing line, pause and ask:could I rename something instead?

A Real-World Header Template

Copy this for your own programs — it follows conventions used in professional C projects:

/*
 * File:        grade_calculator.c
 * Author:      Your Name
 * Created:     2026-09-21
 * Description: Reads student marks and prints letter grades.
 *              Uses standard 90/80/70/60 grade boundaries.
 * Compile:     gcc grade_calculator.c -o grades
 */

Thirty seconds of writing, hours of future confusion prevented.