Online Compiler logoOnline Compiler
Start Coding

JavaScript Tutorial

Comments in JavaScript — Single-Line, Multi-Line, and JSDoc

Comments are notes in your code that the JavaScript engine ignores.

They help explain intent, document APIs, and improve team collaboration.

Contents

IntroductionWhy We Need ItSyntaxBasic ExampleReal World ExampleMultiple Use CasesComparisonCommon MistakesInterview QuestionsPractice ProblemFAQRelated TopicsTry It Yourself

Quick Actions

Open CompilerRun First Example

Why We Need It

Good comments reduce debugging time and make code maintainable.

They also preserve the reasoning behind decisions long after the code is written.

Syntax

// Single-line comment
/* Multi-line comment */
/** JSDoc comment */

Basic Example

1. Comments Are Ignored by the Engine

// This entire line is a comment
console.log("Hello World"); // Inline comment

/* Multi-line
   comment */

const name = "John"; // Comment ignored

Comments are removed during parsing and never executed.

Run Code

Real World Example

2. Single-Line Comment Patterns

// This is a single-line comment
const user = "Alice"; // Inline comment

// Temporarily disable a line
// console.log(user);

Use // for short, quick explanations or inline notes.

Run Code

Multiple Use Cases

What Are Comments?

Comments are notes in your code that are completely ignored by the JavaScript engine during execution.

Comments serve as documentation for other developers (and your future self) to understand the code's purpose.

They help explain complex logic, document APIs, and provide context that the code alone cannot convey.

Comments do not affect performance or code execution - they are purely for human readers.

Professional code always includes meaningful comments that explain the "why" behind decisions.

Single-Line Comments (//)

Single-line comments start with // and extend to the end of the line.

Everything after // on that line is treated as a comment.

Use single-line comments for quick notes, inline explanations, or disabling single lines.

They are the most common comment type for everyday use.

You can place them on their own line or at the end of a code line.

Multi-Line Comments (/* */)

Multi-line comments start with /* and end with */.

They can span multiple lines and are useful for longer explanations.

Multi-line comments are often used for file headers, function descriptions, and temporarily disabling code blocks.

Always ensure the closing */ is present to avoid syntax errors.

They can also be used on a single line when the comment is brief.

JSDoc Comments (/** */)

JSDoc is a standardized documentation format using /** */ with special tags.

JSDoc comments provide structured metadata for functions, classes, and parameters.

IDEs use JSDoc to provide IntelliSense hints, type information, and auto-completion.

JSDoc tags start with @ and provide specific information like parameters, return types, and examples.

JSDoc is especially valuable in larger projects and when working with TypeScript.

Commenting Best Practices

Write comments that explain "why" the code works this way, not just "what" it does.

Avoid stating the obvious - don't comment lines that are already clear.

Keep comments concise but complete - avoid cryptic abbreviations.

Use proper grammar and clear language to maintain professionalism.

Update comments when you refactor code to keep them accurate.

Comments should be at the same indentation level as the code they describe.

Commenting Strategies for Different Scenarios

Different situations require different commenting approaches.

Complex algorithms benefit from detailed inline explanations.

Business logic should be documented with context about why decisions exist.

Workarounds need explaining why the obvious approach doesn't work.

Edge cases should document handling and expected behavior.

When NOT to Comment

Good code should be self-documenting through clear naming and structure.

Avoid comments that restate what the code obviously does.

Remove comments when code is refactored and they become obsolete.

Don't use comments to hide broken code - fix or delete it.

Comments should never contain sensitive information like passwords or API keys.

More Examples

3. Multi-Line Comment Usage

/*
  File Header
  Author: Team
*/

/* Disable a block temporarily
const oldApproach = () => "disabled";
*/

Use /* */ for longer explanations or block comments.

Run Code

4. JSDoc for Functions

/**
 * Adds two numbers
 * @param {number} a
 * @param {number} b
 * @returns {number}
 */
function add(a, b) {
  return a + b;
}

JSDoc provides structured documentation and IDE hints.

Run Code

5. Good vs Bad Comments

// BAD: Restates obvious code
const total = price + tax; // add tax

// GOOD: Explains why
// Include sales tax per state policy
const totalWithTax = price + tax;

Comments should explain the why, not the obvious what.

Run Code

Comparison

Without

// BAD
const total = price + tax; // add tax

With

// GOOD
// Include sales tax per policy
const total = price + tax;

Common Mistakes and Fixes

Leaving outdated comments after refactoring

Update or remove comments when code changes. Outdated comments are worse than no comments.

Over-commenting obvious code

Let clean code speak for itself. Comment only where additional context adds value.

Using comments to hide broken code

Remove commented-out code. If it's needed, it's in version control. If not, delete it.

Forgetting to close multi-line comments (/* */)

Always match /* with */. Unclosed comments cause SyntaxError.

Including sensitive information in comments

Never put passwords, API keys, or personal data in comments. Use environment variables.

Interview Questions

Do comments affect performance?

No. Comments are stripped during parsing and never executed.

When should you use JSDoc?

Use it for shared functions, APIs, and larger codebases.

What makes a comment good?

It explains the why, not the obvious what.

Practice Problem

Practice: Add a single-line and multi-line comment to explain a function.

function greet(name) {
  return "Hello, " + name + "!";
}

One Possible Solution

// Greets a user by name
function greet(name) {
  /* Returns a friendly greeting */
  return "Hello, " + name + "!";
}

Frequently Asked Questions

Do comments affect JavaScript performance?

No. Comments are stripped during parsing and never reach the engine. They have zero performance impact.

Should I comment every line of code?

No. Comment should explain "why" not "what". Well-named variables and functions reduce comment needs significantly.

What's the difference between // and /* */?

// is for single-line comments. /* */ is for multi-line comments. Use whichever is more convenient for your comment length.

When should I use JSDoc?

Use JSDoc for functions in shared modules, APIs, libraries, and larger codebases where IDE hints and documentation matter.

Can I nest comments inside each other?

Single-line comments can nest inside multi-line, but not the other way. Multi-line comments cannot nest within each other.

Do I need to write JSDoc for every function?

Not always. JSDoc is valuable for public APIs and complex functions. Simple utility functions might not need it.

What's the best way to document complex algorithms?

Use multi-line comments and explain the algorithm's approach, time complexity, and why it's used rather than simpler approaches.

How do I generate documentation from JSDoc?

Use tools like TypeDoc, ESDoc, or JSDoc CLI to automatically generate HTML documentation from JSDoc comments.

Try It Yourself

Try the comment example and see how only the code executes.

Run Comment ExampleOpen Compiler
← Previous topicNext topic →