What Are Comments in C?

A comment is text written for humans. It explains the purpose of a program, a function or a tricky line, and the compiler ignores it. Comments make code easier to read, review and maintain, but they have no effect on the generated machine code.

C offers two styles. The original block comment starts with /* and ends at the next */, and can cover one line or many. The line comment starts with // and runs to the end of the physical line. Line comments were added in the C99 standard, borrowed from C++, so a strict C89 compiler rejects them.

Example 1: Block and line comments together

/*
 * e8_1.c - block comment spanning several lines.
 * Purpose: convert a battery ADC count into millivolts.
 */
#include <stdio.h>

/* Reference voltage of the ADC, in millivolts */
#define VREF_MV 3300

int main(void)
{
    int adc = 2048;                 // 12-bit count (C99 line comment)
    int mv  = adc * VREF_MV / 4095; /* scale to millivolts */

    printf("adc=%d -> %d mV\n", adc, mv);   // output line
    return 0;
}

gcc -std=c17 -Wall -Wextra e8_1.c -o e8_1
./e8_1

adc=2048 -> 1650 mV

The output is 1650 mV: the ADC reading is about half of full scale, so the voltage is about half of the 3300 mV reference. The file opens with a multi-line block comment that states the purpose, a one-line block comment documents the constant, and the two line comments annotate the code they sit beside.

Because older compilers reject //, you can see what a strict C89 build says. The same file, compiled with -std=c89 -pedantic, produces:

e8_1.c: In function ‘main’:
e8_1.c:12:37: error: C++ style comments are not allowed in ISO C90
   12 |     int adc = 2048;                 // 12-bit count (C99 line comment)
      |                                     ^

If you must support an ancient toolchain, stick to /* */. Modern projects built with C99 or later can use both, but many style guides still choose one style for consistency. For kernel code, read the coding-style document of the tree you are working on.

Where Can Comments Be Written in C?

You may place a comment almost anywhere that whitespace is allowed: between statements, at the end of a line, between function arguments or inside a long expression. The exception is inside a string literal or a character constant, where /* and // are just characters.

Why Comments in C Cannot Be Nested

A block comment ends at the first */ that follows its opening /*. The compiler does not count levels of opening markers. So when you wrap code that already contains a block comment inside another block comment, the outer comment ends too early, and the remaining text is read as real code.

Example 2: The nesting trap and the safe alternative

The first file tries to switch off two statements by wrapping them in a comment. One of them carries its own comment.

#include <stdio.h>

int main(void)
{
    /* disable the debug block
    printf("step 1\n");   /* first message */
    printf("step 2\n");
    */
    printf("done\n");
    return 0;
}

gcc -std=c17 -Wall -Wextra e8_2_bad.c -o bad

e8_2_bad.c: In function ‘main’:
e8_2_bad.c:6:27: warning: "/*" within comment [-Wcomment]
    6 |     printf("step 1\n");   /* first message */
      |                            
e8_2_bad.c:8:6: error: expected expression before ‘/’ token
    8 |     */
      |      ^

GCC first warns that it found /* inside a comment (-Wcomment), then fails at the stray */. The robust way to remove a block of code is the preprocessor:

#include <stdio.h>

int main(void)
{
#if 0
    printf("step 1\n");   /* first message */
    printf("step 2\n");
#endif
    printf("done\n");
    return 0;
}

gcc -std=c17 -Wall -Wextra e8_2_good.c -o good
./good

done

#if 0 ... #endif removes everything between the two lines before the compiler parses it, and it nests properly with other comments and with other #if blocks. Remember to delete dead code before committing: version control, not comment blocks, is where old code should live.

What Happens to a Comment During Compilation?

Before the compiler analyses your program, the preprocessor runs. In one of its early translation phases every comment is replaced by a single space. That means a comment separates tokens exactly like a space does, and it can never glue two tokens together.

Example 3: Comment markers inside strings, and the one-space rule

#include <stdio.h>

int main(void)
{
    printf("/* this is just text */\n");
    printf("// so is this\n");
    char slash = '/';
    char star  = '*';
    printf("slash=%c star=%c\n", slash, star);
    printf("a" /* comment between literals */ "b\n");
    return 0;
}

gcc -std=c17 -Wall -Wextra e8_3.c -o e8_3
./e8_3

/* this is just text */
// so is this
slash=/ star=*
ab

The two printf calls print the marker characters because they sit inside string literals. The character constants '/' and '*' are plain characters too. The last line shows two adjacent string literals separated by a comment: the comment becomes a space, the literals concatenate, and the output is ab.

To see the one-space rule directly, run only the preprocessor on this two-line file. The second line is deliberately wrong:

int/**/count = 10;
int total = 1/**/2;

gcc -E -P e8_3c.c

int count = 10;
int total = 1 2;

e8_3c.c:2:18: error: expected ‘,’ or ‘;’ before numeric constant
    2 | int total = 1/**/2;
      |                  ^

The Backslash Trap in Line Comments

A backslash at the very end of a physical line joins that line with the next one before comments are recognised. If a // comment ends with a backslash, the following line becomes part of the comment, and real code silently disappears.

Example 4: A line comment that swallows code

#include <stdio.h>

int main(void)
{
    int limit = 10;
    // check the limit \
    limit = 99;
    printf("limit = %d\n", limit);
    return 0;
}

gcc -std=c17 -Wall -Wextra e8_4.c -o e8_4
./e8_4

e8_4.c: In function ‘main’:
e8_4.c:6:5: warning: multi-line comment [-Wcomment]
    6 |     // check the limit \
      |     ^
limit = 10

The program printed 10, not 99. The assignment limit = 99; was absorbed into the comment on the line above, and the compiler only hinted at it with multi-line comment from -Wcomment. This bug is common in Windows paths written in comments, such as // copy to C:\drivers\. Never end a line comment with a backslash, and keep -Wall switched on so the warning is visible.

How to Write Good Comments in C

The best comment is the one the code does not need, because a clear name already says everything. When a comment is needed, it should explain why, not repeat what the code already shows.

A short block comment above a function that states its purpose, inputs, outputs and any constraint helps both humans and documentation tools. A simple style looks like this:

/**
 * ep_scale_adc - convert a raw ADC count to millivolts
 * @count: 12-bit ADC reading, 0 to 4095
 * @vref_mv: reference voltage in millivolts
 *
 * Return: voltage in millivolts, rounded down.
 * Context: safe to call from interrupt handlers (no blocking).
 */
static int ep_scale_adc(int count, int vref_mv)
{
    return count * vref_mv / 4095;
}

Tools such as Doxygen and the kernel-doc script read comments of this form. The first line holds the function name and a one-line summary, followed by the parameters. In hardware code, comments are also the right place to record register addresses, units, timing limits and the datasheet section you used.

Common Mistakes with Comments in C

Performance note: comments cost nothing at run time and nothing in the binary. They are removed before compilation, so describe as much as helps. Security note: comments can mislead reviewers. A comment that claims a buffer is checked while the code does not check it is a classic source of vulnerabilities, so review what the code does, not what the comment says.

Quiz: Test Your Understanding of Comments in C

Interview Questions on Comments in C

Summary and Key Takeaways

• Comments in C come in two styles: block /* */ from C89 and line // from C99.
• They are removed during preprocessing, each replaced by a single space, so they never affect the binary.
• Comment markers inside string or character constants are ordinary text.
• Block comments do not nest. Use #if 0 to disable code safely.
• A backslash at the end of a line comment splices in the next line, a classic silent bug.
• Write comments that explain why, keep them current and follow your project style.

Conclusion

You now understand comments in C well enough to use them safely and to explain their rules in an interview. They look simple, but the nesting limit, the one-space replacement and the backslash splice are exactly the details that separate careful engineers from careless ones. With this lecture the Elements of C chapter on expressions, statements and comments is complete. In the next chapter we move on to the operators in detail, building directly on what you learned about expressions. Keep following the free embedded systems course and the free Linux device drivers course to build a strong foundation for product-company interviews.

Frequently Asked Questions About Comments in C