Comment¶
Comment is text within the source code that is not executed as part of the program but serves to provide human-readable explanations, documentation, or annotations. Comments are used to describe the purpose of code, explain complex algorithms, or make notes for future developers.
1. Category¶
1.1. Styles¶
Comment styles are the conventions and syntax used to write comments in programming languages. Since each language has its own rules, projects should define and follow a consistent style guide. Comments improve readability, reduce ambiguity, and make code reviews faster.
-
Types and Scopes
-
Inline Comments
Inline comments are written on the same line as code to clarify intent when the code alone is not obvious. They should be brief and focused on why the code exists, not what the syntax already shows.
-
Single-Line Comments
Single-line comments document a nearby line or short block. They are useful for assumptions, constraints, or decisions that are not obvious from identifiers and control flow.
-
Multi-Line Comments
Multi-line comments document broader context such as algorithm trade-offs, data contracts, or migration notes. Prefer concise blocks and keep them close to the code they describe.
-
Comment Tags
Comment tags mark actionable items such as incomplete work, defects, or temporary workarounds. Teams should standardize allowed tags and review them regularly.
-
Documentation Comments
Documentation comments are structured comments used by documentation tools (for example, Doxygen, Javadoc, and Sphinx). They describe public APIs and behavior contracts.
/// @file Demonstrates a documented addition function. #include <iostream> /// @brief Adds two integers. /// @param left First operand. /// @param right Second operand. /// @return Sum of the operands. int add(int left, int right) { return left + right; } int main() { std::cout << add(1, 2) << std::endl; return 0; }
-
1.2. Tags¶
Comment Tags are used to annotate and organize code with additional information to highlight specific aspects of the codebase.
Tags improve readability and maintainability by making technical debt and follow-up actions visible. Use tags intentionally and keep them traceable to real tasks or decisions.
-
Types and Scopes
-
TODOIndicates planned work that is not finished yet.
-
FIXMEMarks known defects that require correction.
-
XXXFlags code that is risky, ambiguous, or requires careful review.
-
HACKIndicates a temporary workaround with known limitations.
-
BUGMarks known bug locations to triage and follow-up.
-
OPTIMIZEMarks code paths that are correct but performance-sensitive.
-
NOTEHighlights important context that may be missed when reading quickly.
-
DEPRECATEDIndicates APIs or features scheduled for removal.
-
NITDenotes minor style or readability suggestions.
-
2. Principles¶
-
Clarity
Write comments that explain intent, assumptions, and trade-offs. If the code already states what is happening, prefer improving names or structure instead of repeating it in comments.
-
Maintainability
Keep comments synchronized with implementation. Outdated comments are more harmful than missing comments because they mislead reviewers and maintainers.
-
Collaboration
Use a shared vocabulary, consistent tag definitions, and predictable formatting so teams can scan and act quickly during reviews.
-
Sparingly
Comment only when the added context is valuable. Prefer self-explanatory code and reserve comments for non-obvious decisions.
-
Consistency
Apply one style guide for comment syntax, capitalization, punctuation, and tags across the repository.
-
Update
Review and clean up comments during refactors and pull requests, including removing stale
TODOandHACKentries.
3. References¶
- Python Enhancement Proposals PEP 350 – Codetags page.
- Wikipedia comment page.