Effective Commenting Strategies

Good comments explain the "why" behind code, not the "what." Use these strategies to write comments that enhance code maintainability without creating maintenance burden.

When to Use

• Adding comments to new code
• Reviewing existing comments for quality
• Establishing team commenting standards
• Optimizing comment density for readability
• Handling performance-sensitive code with comments

Core Principle: Intent Over Repetition

Good comments should:

• Not repeat code or explain what the code does
• Clarify intent at a higher abstraction level than the code
• Act as navigation like book headings or table of contents
• Help maintenance by explaining the original programmer's intent
• **Be efficient"—reading one English comment is faster than parsing 20 lines of code

Rule: If the code already explains everything, a comment that repeats it provides no value.

Comment Types

Marker Comments

Purpose: Remind developers of incomplete work (not intended for production)

Requirements:

• Use standardized markers (e.g.,

  ***

  ,

  TBD

  ,

  TODO

  )
• Make markers mechanically searchable
• Include in release checklist to prevent shipping known defects

Action: Search for all markers before release to ensure no incomplete code ships.

Explanatory Comments

Purpose: Explain complex, tricky, or sensitive code

Strategy:

• If code is complex enough to need explanation, refactor the code first
• Make the code itself clearer
• Then use summary or intent comments if still needed

Summary Comments

Purpose: Condense several lines of code into one or two sentences

Value: More valuable than code-repeating comments because readers can scan them faster than reading code

When to use: Particularly helpful when non-original authors need to modify code

Intent Comments

Purpose: Explain the purpose of a code section at the intent/problem level

Level: Operates more at the problem level than the solution level

Example:

• Intent: "Get current employee information"
• Solution/Summary: "Update employeeRecord object"

Metadata Comments

Purpose: Record information that cannot be expressed in code

Includes:

• Copyright notices
• Confidentiality statements
• Version numbers
• Design notes
• Requirement references
• Online reference pointers
• Optimization notes
• Tool-required comments (e.g., Javadoc)

Maintainable Comment Style

Avoid High-Maintenance Styles

Do not use styles that require manual alignment:

• ❌ Leader dots (

  ...

  ) connecting variables and descriptions
• ❌ Asterisk boxes (

  *

  ) surrounding paragraphs—requires adjusting both sides
• ❌ Plus-sign underlines (

  +---+

  )—requires precise positioning when text length changes

Principle: Prefer accurate comments over pretty comments. If maintaining aesthetics requires tedious work, abandon that style.

Syntax Guidelines

For Java and C++:

• Single-line comments: Use

  //

  syntax, keep comments short
• Multi-line comments: Use

  /* ... */

  syntax—easier to maintain than manually wrapped

  //

  lines

For emphasis: Use standard-length lines (via editor macros), not lines that vary with comment length

Comment Density Guidelines

Optimal Density

IBM Research Finding: Approximately 1 comment per 10 statements maximizes code clarity

• Below this density: Code becomes difficult to understand
• Above this density: Readability decreases

Avoid Quotas

Do not enforce rigid standards like "at least 1 comment per 5 lines"

Reason: This addresses the symptom (lack of comments) without solving the root cause (unclear code)

Performance Considerations

Principle: Do not avoid comments due to performance concerns (e.g., interpreted environments, network transmission overhead)

Solution: Create a separate release build

Implementation: Run a tool during the build process to automatically strip comments from the production version

Pseudocode Programming Process (PPP) Comment Efficiency

When using the Pseudocode Programming Process:

1. Recognize the pattern: Effective PPP naturally results in "a comment every few lines"
2. Understand the nature: Comment quantity is a side effect of the process, not a goal
3. Focus on efficiency: Don't count comments—evaluate whether each comment is effective
4. Assess sufficiency: Comments are sufficient if they:
   • Describe why the code was written
   • Meet the other standards in this skill

Conclusion: If comments explain "why" and meet quality standards, the quantity is adequate—don't worry about the number.