Comment (computer programming)

Overview

Comments are generally formatted as either block comments (also called prologue comments or stream comments) or line comments (also called inline comments).

Block comments delimit a region of source code which may span multiple lines. This region is specified with a start delimiter and an end delimiter. Some programming languages (such as MATLAB) allow block comments to be recursively nested inside one another, but others (such as Java) do not.

Line comments either start with a comment delimiter and continue until the end of the line, or in some cases, start at a specific column (character line offset) in the source code, and continue until the end of the line.

Some programming languages employ both block and line comments with different comment delimiters. For example, C++ has block comments delimited by /* and */ that can span multiple lines and line comments delimited by //. Other languages support only one type of comment. For example, Ada comments are line comments: they start with -- and continue to the end of the line.

Uses

How best to make use of comments is subject to dispute; different commentators have offered varied and sometimes opposing viewpoints. There are many different ways of writing comments and many commentators who offer sometimes conflicting advice.

Planning and reviewing

Comments can be used as a form of pseudocode to outline intention prior to writing the actual code. In this case it should explain the logic behind the code rather than the code itself.

If this type of comment is left in, it simplifies the review process by allowing a direct comparison of the code with the intended results. A common logical fallacy is that code that is easy to understand does what it's supposed to do.

Code description

Comments can be used to summarize code or to explain the programmer's intent. According to this school of thought, restating the code in plain English is considered superfluous; the need to re-explain code may be a sign that it is too complex and should be rewritten, or that the naming is bad.

"Don't document bad code – rewrite it." "Good comments don't repeat the code or explain it. They clarify its intent. Comments should explain, at a higher level of abstraction than the code, what you're trying to do."

Comments may also be used to explain why a block of code does not seem to fit conventions or best practices. This is especially true of projects involving very little development time, or in bug fixing. For example:

Algorithmic description

Sometimes source code contains a novel or noteworthy solution to a specific problem. In such cases, comments may contain an explanation of the methodology. Such explanations may include diagrams and formal mathematical proofs. This may constitute explanation of the code, rather than a clarification of its intent; but others tasked with maintaining the code base may find such explanation crucial. This might especially be true in the case of highly specialized problem domains; or rarely used optimizations, constructs or function-calls.

For example, a programmer may add a comment to explain why an insertion sort was chosen instead of a quicksort, as the former is, in theory, slower than the latter. This could be written as follows:

Resource inclusion

Logos, diagrams, and flowcharts consisting of ASCII art constructions can be inserted into source code formatted as a comment. Further, copyright notices can be embedded within source code as comments. Binary data may also be encoded in comments through a process known as binary-to-text encoding, although such practice is uncommon and typically relegated to external resource files.

The following code fragment is a simple ASCII diagram depicting the process flow for a system administration script contained in a Windows Script File running under Windows Script Host. Although a section marking the code appears as a comment, the diagram itself actually appears in an XML CDATA section, which is technically considered distinct from comments, but can serve similar purposes.

Although this identical diagram could easily have been included as a comment, the example illustrates one instance where a programmer may opt not to use comments as a way of including resources in source code.

Metadata

Comments in a computer program often store metadata about a program file.

In particular, many software maintainers put submission guidelines in comments to help people who read the source code of that program to send any improvements they make back to the maintainer.

Other metadata includes: the name of the creator of the original version of the program file and the date when the first version was created, the name of the current maintainer of the program, the names of other people who have edited the program file so far, the URL of documentation about how to use the program, the name of the software license for this program file, etc.

When an algorithm in some section of the program is based on a description in a book or other reference, comments can be used to give the page number and title of the book or Request for Comments or other reference.

Debugging

A common developer practice is to comment out a code snippet, meaning to add comment syntax causing that block of code to become a comment, so that it will not be executed in the final program. This may be done to exclude certain pieces of code from the final program, or (more commonly) it can be used to find the source of an error. By systematically commenting out and running parts of the program, the source of an error can be determined, allowing it to be corrected.

An example of commenting out code for exclusion purposes is below:

The above code fragment suggests that the programmer opted to disable the debugging option for some reason.

Many IDEs allow quick adding or removing such comments with single menu options or key combinations. The programmer has only to mark the part of text they want to (un)comment and choose the appropriate option.

Automatic documentation generation

Programming tools sometimes store documentation and metadata in comments. These may include insert positions for automatic header file inclusion, commands to set the file's syntax highlighting mode, or the file's revision number. These functional control comments are also commonly referred to as annotations. Keeping documentation within source code comments is considered as one way to simplify the documentation process, as well as increase the chances that the documentation will be kept up to date with changes in the code.

Examples of documentation generators include the programs Javadoc for use with Java, Ddoc for D, Doxygen for C, C++, Java, IDL, and PHPDoc for PHP. Forms of docstring are supported by Python, Lisp, Elixir, and Clojure.

C#, F# and Visual Basic implement a similar feature called "XML Comments" which are read by IntelliSense from the compiled .NET assembly.

Syntax extension

Occasionally syntax elements that were originally intended to be comments are re-purposed to convey additional information to a program, such as "conditional comments". Such "hot comments" may be the only practical solution that maintains backward-compatibility, but are widely regarded as a kludge.

Stress relief

Sometimes comments in source code are used as a way to relieve stress by commenting about development tools, competitors, employers, working conditions, or the quality of the code itself. The occurrence of this phenomenon can be easily seen from online resources that track profanity in source code.

Normative views

There are various normative views and long-standing opinions regarding the proper use of comments in source code. Some of these are informal and based on personal preference, while others are published or promulgated as formal guidelines.

Need for comments

Technical commentators have documented varying viewpoints on whether and when comments are appropriate in source code. Some commentators assert that source code should be written with few comments, on the basis that the source code should be self-explanatory or self-documenting. Others suggest code should be extensively commented (it is not uncommon for over 50% of the non-whitespace characters in source code to be contained within comments).

In between these views is the assertion that comments are neither beneficial nor harmful by themselves, and what matters is that they are correct and kept in sync with the source code, and omitted if they are superfluous, excessive, difficult to maintain or otherwise unhelpful.

Comments are sometimes used to document contracts in the design by contract approach to programming.

Level of detail

Depending on the intended audience of the code and other considerations, the level of detail and description may vary considerably.

For example, the following Java comment would be suitable in an introductory text designed to teach beginning programming:

This level of detail, however, would not be appropriate in the context of production code, or other situations involving experienced developers. Such rudimentary descriptions are inconsistent with the guideline: "Good comments ... clarify intent." Further, for professional coding environments, the level of detail is ordinarily well-defined to meet a specific performance requirement defined by business operations.

Styles

There are many stylistic alternatives available when considering how comments should appear in source code. For larger projects involving a team of developers, comment styles are either agreed upon before a project starts, or evolve as a matter of convention or need as a project grows. Usually programmers prefer styles that are consistent, non-obstructive, easy to modify, and difficult to break.

The following code fragments in C demonstrate just a tiny example of how comments can vary stylistically, while still conveying the same basic information:

Factors such as personal preference, flexibility of programming tools, and other considerations tend to influence the stylistic variants used in source code. For example, Variation Two might be disfavored among programmers who do not have source code editors that can automate the alignment and visual appearance of text in comments.

Software consultant and technology commentator Allen Holub is one expert who advocates aligning the left edges of comments:

End-of-line

In this form, all the text from the ASCII characters // to the end of the line is ignored.

Different styles can be chosen for different areas of code, from individual lines to paragraphs, routines, files, and programs. If the syntax supports both line comments and block comments, one method is to use line comments only for minor comments (declarations, blocks and edits) and to use block comments to describe higher-level abstractions (functions, classes, files and modules).

Sometimes projects try to enforce rules like "one comment every ten lines". These kinds of rules can be counterproductive when too rigorous, but may provide a useful standard of measurement and consistency if the project participants deem it necessary.

Tags

Programmers may use informal tags in comments to assist in indexing common issues. They may then be able to be searched for with common programming tools, such as the Unix grep utility or even syntax-highlighted within text editors. These are sometimes referred to as "codetags" or "tokens".

Such tags differ widely, but might include:

FIXME - should be corrected.

HACK - a workaround.

TODO - something to be done.

UNDONE - a reversal or "roll back" of previous code.

XXX - warn other programmers of problematic or misguiding code

UX - user experience, notice about non-trivial code.

Comparison

Typographic conventions to specify comments vary widely. Further, individual programming languages sometimes provide unique variants. For a detailed review, please consult the programming language comparison article.

Ada

The Ada programming language uses '--' to indicate a comment up to the end of the line.

For example:

AppleScript

This section of AppleScript code shows the two styles of comments used in that language.

BASIC

This BASIC code fragment is a completely functioning program in which the REM ("REMark") keyword is used to add comments that describe what the program does.

Any text on a line after an ' (apostrophe) character is also treated as a comment in Microsoft BASICs, including QuickBasic, QBasic, Visual Basic, Visual Basic .NET, and VBScript - and in descendants such as FreeBASIC and Gambas.

An example in Visual Basic .NET:

C

This C code fragment demonstrates the use of a prologue comment or "block comment" to describe the purpose of a conditional statement. The comment explains key terms and concepts, and includes a short signature by the programmer who authored the code.

Since C99, it has also been possible to use the // syntax from C++, indicating a single-line comment.

ColdFusion

ColdFusion uses comments similar to HTML comments, but instead of two dashes, it uses three. These comments are caught by the ColdFusion engine and not printed to the browser.

Fortran IV

This Fortran IV code fragment demonstrates how comments are used in that language, with the comments themselves describing the basic formatting rules.

Fortran 90

This Fortran code fragment demonstrates how comments are used in that language, with the comments themselves describing the basic formatting rules.

Haskell

Single line comments in Haskell start with '--' (two hyphens), and multiple line comments start with '{-' and end with '-}'.

Haskell also provides a literate programming method of commenting known as "Bird Style". In this all lines starting with > are interpreted as code, everything else is considered a comment. One additional requirement is that you always leave a blank line before and after the code block:

Java

This Java code fragment shows a block comment used to describe the setToolTipText method. The formatting is consistent with Sun Microsystems Javadoc standards. The comment is designed to be read by the Javadoc processor.

JavaScript

JavaScript uses // to precede comments and /* */ for multi-line comments.

MATLAB

In MATLAB's programming language, the '%' character indicates a single-line comment. Multi line comments are also available via %{ and %} brackets and can be nested, e.g.

OCaml

OCaml uses nestable comments, which is useful when commenting a code block.

Pascal

In Niklaus Wirth's pascal family of languages (including Modula-2 and Oberon), comments are opened with '(*' and completed with '*)'.

for example:

Perl

Line comments in Perl, and many other scripting languages, begin with a hash (#) symbol.

Instead of a regular block commenting construct, Perl uses Plain Old Documentation, a markup language for literate programming, for instance:

PHP

Comments in PHP can be either in C++ style (both inline and block), or use hashes. PHPDoc is a style adapted from Javadoc and is a common standard for documenting PHP code.

PowerShell

Comments in Windows PowerShell

Python

Comments in Python use the hash (#) character, as in the two examples in this code:

Specific block comments don't exist in Python, but a bare string literal represented by a triple-quoted string could be used. In the examples below, the triple double-quoted strings act in this way as comments, but are also treated as docstrings:

Ruby

Comments in Ruby.

Single line commenting: (line starts with hash "#")

Multi-line commenting: (comments goes between keywords "begin" and "end")

SQL

Comments in SQL are in single-line-only form, when using two dashes:

The syntax for Transact-SQL also supports alternative formats for specifying comments. One format supported by this syntax is identical to the "block comment" style used in the syntax for C++ and Java.

Swift

Single-line comments begin with two forward-slashes (//):

Multiline comments start with a forward-slash followed by an asterisk (/*) and end with an asterisk followed by a forward-slash (*/):

Multiline comments in Swift can be nested inside other multiline comments. You write nested comments by starting a multiline comment block and then starting a second multiline comment within the first block. The second block is then closed, followed by the first block:

XML

Comments in XML (or HTML) are introduced with

and can spread over several lines until the terminator,

For example,

Security issues

In interpreted languages the comments are viewable to the end user of the program. In some cases, such as sections of code that are "commented out", this may present a security vulnerability.