Comment (computer programming)

For comments in Wikipedia markup, see Help:Wiki markup § Character formatting, and WP:COMMENT.

"/*" and "*/" redirect here. For their use in Wikipedia edit summaries, see Help:Edit summary § Section editing.

An illustration of Java source code with prologue comments indicated in red and inline comments in green. Program code is in blue.

In computer programming, a comment is text embedded in source code that a translator (compiler or interpreter) ignores. Generally, a comment is an annotation intended to make the code easier for a programmer to understand – often explaining an aspect that is not readily apparent in the symbolic (non-comment) code.

Comments can be processed by some development tools to provide capabilites such as API document generation, static analysis, and version control integration.

The syntax of comments varies considerably by programming language. But generally, the flexibility supported by comments allows for a wide degree of style variability. To promote uniformity, conventions for their style are commonly part of a programming style guide. But, best practices are disputed and contradictory.

Common attributes

Support for code comments is defined by each programming language. The features differ by language, but there are several common attributes that apply throughout.

Most languages support formatting comments either as a block (also called prologue or stream) or a line (also called inline).

A block comment is delimited with special text that marks the start and end of the block. It can span multiple lines or occupy any part of a line. Some languages (such as MATLAB) allow block comments to be recursively nested inside one another, but others (such as Java) do not.

In modern languages, a line comment starts with a delimiter and continues until the end of the line. Some older languages designated a column at which subsequent text is considered comment text.

Most modern languages support both block and line comments – using different delimiters for each. For example, C, C++ and their many variants support block comments delimited by /* and */ and line comments delimited by //. Other languages support only one type of comment.

Examples of use

Describe intent

Comments can explain the author's intent. Some contend that describing what the code does is superfluous; the need to explain what it does is a sign that it is too complex and should be re-worked.

"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."

Highlight unusual practice

Comments may explain why a choice was made to write code that is counter to convention or best practice. For example:

' Second variable dim because of server errors produced when reuse form data.
' No documentation available on server behavior issue, so just coding around it.
vtx = server.mappath("local settings")

The example below explains why an insertion sort was chosen instead of a quicksort, as the former is, in theory, slower than the latter.

 list = [f (b), f (b), f (c), f (d), f (a), ...];
 // Need a stable sort. Besides, the performance really does not matter.
 insertion_sort (list);

Algorithmic description

Comments can describe an algorithm as pseudocode. This could be done before writing the code as a first draft. If left in the code, it can simplify code review by allowing comparison of the resulting code with the intended logic. For example:

/* loop backwards through all elements returned by the server 
(they should be processed chronologically)*/
for (i = (numElementsReturned - 0); i >= 1; i--) {
    /* process each element's data */
    updatePattern(i, returnedElements[i]);
}

Sometimes code contains a novel or noteworthy solution that warrants an explanatory comment. Such explanations might be lengthy and include diagrams and formal mathematical proofs. This may describe what the code does rather than intent, but may be useful for maintaining the code. This might apply for highly specialized problem domains or rarely used optimizations, constructs or function-calls.

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.

<!-- begin: wsf_resource_nodes -->
<resource id="ProcessDiagram000">
<![CDATA[
 HostApp (Main_process)
    |
    V
script.wsf (app_cmd) --> ClientApp (async_run, batch_process)
                |
                |
                V
         mru.ini (mru_history)  
]]>
</resource>

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 are used for store metadata. Sometimes, a software maintainer puts submission guidelines in comments to help people send improvements to the maintainer. Other common metadata includes the name of the original author and subsequent maintainers, dates when first written and modified, link to development and user documentation, software license information.

Some programming tools write metadata into the code as comments. This may include insert positions for automatic header file inclusion, commands to set the file's syntax highlighting mode, or the file's revision number.

Reference

When some aspect of the code is based on information in an external reference, comments link to the reference. For example as a URL or book name and page number.

Comment out

A common developer practice is to comment out one or more lines of code. The programmer adds comment syntax that converts code into comments so that what was executable code will no longer be executed at runtime. Sometimes this technique is used to find the cause of a bug. By systematically commenting out and running parts of the program, the offending source code can be located.

Many IDEs support adding and removing comments with convenient user interface such as a keyboard shortcut.

Documentation generation

A documentation generator can parse information from a codebase to generate API documentation. Many support reading information from comments to control the content and formatting of the resulting document. Some claim that storing documentation information in code comments simplifies the documenting process, as well as increase the chances that the documentation will be kept up to date. Examples include Javadoc, Ddoc, Doxygen, Visual Expert and PHPDoc. Forms of docstring are supported by Python, Lisp, Elixir, and Clojure. C#, F# and Visual Basic .NET 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.

One specific example are docblocks, which are specially-formatted comments used to document a specific segment of code. This makes the DocBlock format independent of the target language (as long as it supports comments); however, it may also lead to multiple or inconsistent standards.

Directives

There are cases where the normal comment characters are co-opted to create a special directive for an editor or interpreter.

Two examples of this directing an interpreter are:

• The Unix "shebang" – #! – used on the first line of a script to point to the interpreter to be used.
• "Magic comments" identifying the encoding a source file is using, e.g. Python's PEP 263.

The script below for a Unix-like system shows both of these uses:

#!/usr/bin/env python3
# -*- coding: UTF-8 -*-
print("Testing")

Somewhat similar is the use of comments in C to communicate to a compiler that a default "fallthrough" in a case statement has been done deliberately:

switch (command) {
    case CMD_SHOW_HELP_AND_EXIT:
      do_show_help();
      /* Fall thru */
    case CMD_EXIT:
      do_exit();
      break;
    case CMD_OTHER:
      do_other();
      break;
    /* ... etc. ... */
  }

Inserting such a /* Fall thru */ comment for human readers was already a common convention, but in 2017 the gcc compiler began looking for these (or other indications of deliberate intent), and, if not found, emitting: "warning: this statement may fall through".

Many editors and IDEs will read specially formatted comments. For example, the "modeline" feature of Vim; which would change its handling of tabs while editing a source with this comment included near the top of the file:

# vim: tabstop=8 expandtab shiftwidth=4 softtabstop=4

Stress relief

Sometimes programmers will add comments 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 for a particular community.

Need for comments

Experts have varying viewpoints on whether, and when, comments are appropriate in source code. Some 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:

String s = "Wikipedia"; /* Assigns the value "Wikipedia" to the variable s. */

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

As free-form text, comments can be styled in a wide variety of ways. Many prefer a style that is consistent, non-obstructive, easy to modify, and difficult to break. As some claim that a level of consistency is valuable and worthwhile, a consistent commenting style is sometimes agreed upon before a project starts or emerges as development progresses.

The following C fragments show some of diversity in block comment style:

/*
     This is the comment body.
*/

/***************************\
*                           *
* This is the comment body. *
*                           *
\***************************/

Factors such as personal preference, flexibility of programming tools can influence the commenting style used. For example, the first might be preferred by programmers who use a source code editor that does not automatically format a comment as shown in the second example.

Software consultant and technology commentator Allen Holub advocates aligning the left edges of comments:

 /* This is the style recommended by Holub for C and C++.
  * It is demonstrated in ''Enough Rope'', in rule 29.
  */

 /* This is another way to do it, also in C.
 ** It is easier to do in editors that do not automatically indent the second
 ** through last lines of the comment one space from the first.
 ** It is also used in Holub's book, in rule 31.
 */

In many languages, a line comment can follow symbolic code such that the comment is inline and generally describes the code to the left of it. For example, in this Perl:

print $s . "\n";     # Add a newline character after printing

If a language supports both line and block comments, programming teams may decide upon a convention of when to use which. For example, line comments only for minor comments, and block comments to for higher-level abstractions.

Tags

Programmers often use one of select words – also konwn as tags, codetags and tokens – to categorize the information in a comment. Programmers may leverage these tags by searching for them via a text editor or grep. Some editors highlight comment text based on tags.

Commonly used tags include:

• BUG, DEBUG — identifies a known bug; maybe implying it should be fixed
• FIXME — implies that there is work to do to fix a bug
• HACK, BODGE, KLUDGE — marks a solution that might be considered low quality
• TODO — describes some work to do
• NOTE — relatively general information
• UNDONE — a reversal or "roll back" of previous code

Examples

Comparison

Main article: Comparison of programming languages (syntax) § Comments

Typographic conventions to specify comments vary widely. Further, individual programming languages sometimes provide unique variants.

Ada

Ada supports line comments delimited with '--'. It does not support block comments. For example:

  -- the air traffic controller task takes requests for takeoff and landing
   task type Controller (My_Runway: Runway_Access) is
      -- task entries for synchronous message passing
      entry Request_Takeoff (ID: in Airplane_ID; Takeoff: out Runway_Access);
      entry Request_Approach(ID: in Airplane_ID; Approach: out Runway_Access);
   end Controller;

APL

APL uses ⍝ for a line comment. For example:

⍝ Now add the numbers:
c←a+b ⍝ addition

In dialects that have the ⊣ ("left") and ⊢ ("right") primitives, comments can often be inside or separate statements, in the form of ignored strings:

d←2×c ⊣'where'⊢ c←a+ 'bound'⊢ b

AppleScript

AppleScript supports both line and block comments. For example:

(*
This program displays a greeting.
*)
on greet(myGreeting)
     display dialog myGreeting & " world!"
end greet

-- Show the greeting
greet("Hello")

BASIC

Early versions of BASIC used REM (short for remark) for a line comment.

10 REM This BASIC program shows the use of the PRINT and GOTO Statements.
15 REM It fills the screen with the phrase "HELLO"
20 PRINT "HELLO"
30 GOTO 20

In later variations, including Quick Basic, Q Basic, Visual Basic, Visual Basic .NET, VB Script, FreeBASIC and Gambas a line comment is delimted with apostrophe ('). An example in Visual Basic .NET:

Public Class Form1
    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        ' The following code is executed when the user
        ' clicks the button in the program's window.
        rem comments still exist.

        MessageBox.Show("Hello, World") 'Show a pop-up window with a greeting
    End Sub
End Class

C

In C, C++ and many related languages, the line comment delimiter is // and a block is delimited by /* and */. Originally, C lacked the line comment, but it was added in C99. For example:

 /*
  * Check if we are over our maximum process limit, but be sure to
  * exclude root. This is needed to make it possible for login and
  * friends to set the per-user process limit to something lower
  * than the amount of processes root is running. -- Rik
  */
 if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur
     && !capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE))
     goto bad_fork_free;

Cisco IOS and IOS-XE configuration

The exclamation point (!) may be used to mark comments in a Cisco router's configuration mode, however such comments are not saved to non-volatile memory (which contains the startup-config), nor are they displayed by the "show run" command.

It is possible to insert human-readable content that is actually part of the configuration, and may be saved to the NVRAM startup-config via:

• The "description" command, used to add a description to the configuration of an interface or of a BGP neighbor
• The "name" parameter, to add a remark to a static route
• The "remark" command in access lists

! Paste the text below to reroute traffic manually
config t
int gi0/2
no shut
ip route 0.0.0.0 0.0.0.0 gi0/2 name ISP2
no ip route 0.0.0.0 0.0.0.0 gi0/1 name ISP1
int gi0/1
shut
exit

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.

Such comments are nestable.

 <!--- This prints "Hello World" to the browser.
   <!--- This is a comment used inside the first one.
   --->
 --->
 <cfoutput>
   Hello World<br />
 </cfoutput>

D

D uses C++-style comments, as well as nestable D-style multiline comments, which start with '/+' and end with '+/'.

// This is a single-line comment.
/* This is a multiline comment.

*/
/+ This is a
  /+ nested +/
    comment +/

Fortran IV

This Fortran IV code fragment demonstrates how comments are used in that language, which is very column-oriented. A letter "C" in column 1 causes the entire line to be treated as a comment.

C
C Lines that begin with 'C' (in the first or 'comment' column) are comments
C
      WRITE (6,610)
  610 FORMAT(12H HELLO WORLD)
      END

Note that the columns of a line are otherwise treated as four fields: 1 to 5 is the label field, 6 causes the line to be taken as a continuation of the previous statement; and declarations and statements go in 7 to 72.

Fortran 90

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

!* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
!* All characters after an exclamation mark are considered as comments *
!* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
program comment_test
    print '(A)', 'Hello world' ! Fortran 90 introduced the option for inline comments.
end program

Haskell

Line comments in Haskell start with '--' (two hyphens) until the end of line, and multiple line comments start with '{-' and end with '-}'.

{- this is a comment
on more lines -}
-- and this is a comment on one line
putStrLn "Wikipedia"  -- this is another comment

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:

In Bird-style you have to leave a blank before the code.

> fact :: Integer -> Integer
> fact 0 = 1
> fact (n+1) = (n+1) * fact n

And you have to leave a blank line after the code as well.

Literate programming can also be done in Haskell, using LaTeX. The code environment can be used instead of the Richard Bird's style: In LaTeX style this is equivalent to the above example, the code environment could be defined in the LaTeX preamble. Here is a simple definition:

\usepackage{verbatim}
\newenvironment{code}{\verbatim}{\endverbatim}

later in

% the LaTeX source file
The \verb|fact n| function call computes $n!$ if $n\ge 0$, here is a definition:\\
\begin{code}
fact :: Integer -> Integer
fact 0 = 1
fact (n+1) = (n+1) * fact n
\end{code}
Here more explanation using \LaTeX{} markup

Java

This Java code fragment shows both block and line comments. The block comment is designed to be processed by Javadoc.

/**
 * This is a block comment in Java.
 * The setToolTipText method registers the text to display in a tool tip.
 * The text is displayed when the cursor lingers over the component.
 *
 * @param text  The string to be displayed.  If 'text' is null,
 *              the tool tip is turned off for this component.
 */
public void setToolTipText(String text) {
    // This is an inline comment in Java. TODO: Write code for this method.
}

JavaScript

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

// A single line JavaScript comment
var iNum = 100;
var iTwo = 2; // A comment at the end of line
/*
multi-line
JavaScript comment
*/

Lua

Lua uses double-hyphens, --, for single line comments in a similar way to Ada, Eiffel, Haskell, SQL and VHDL languages. Lua also has block comments, which start with --[[ and run until a closing ]] For example:

--[[A multi-line
long comment
]]
print(20)   -- print the result

A common technique to comment out a segment of code, is to enclose the code between --[[ and --]], as below:

--[[
print(10)
--]]
-- no action (commented out)

In this case, it's possible to enable the code for use (uncomment-out) by adding a single hyphen to the first line:

---[[
print(10)
--]]
--> 10

The --[[ in the first line starts a long comment, and the two hyphens in the last line are still inside that comment. In the second example, the sequence ---[[ starts an ordinary, single-line comment, so that the first and the last lines become independent comments. In this case, the print is outside comments. In this case, the last line becomes an independent comment, as it starts with --.

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.

% These are the derivatives for each term
d = [0 -1 0];

%{
  %{
    (Example of a nested comment, indentation is for cosmetics (and ignored).)
  %}
  We form the sequence, following the Taylor formula.
  Note that we're operating on a vector.
%}
seq = d .* (x - c).^n ./(factorial(n))

% We add-up to get the Taylor approximation
approx = sum(seq)

Nim

Nim uses the '#' character for inline comments. Multi-line block comments are opened with '#[' and closed with ']#'. Multi-line block comments can be nested.

Nim also has documentation comments that use mixed Markdown and ReStructuredText markups. The inline documentation comments use '##' and multi-line block documentation comments are opened with '##[' and closed with ']##'. The compiler can generate HTML, LaTeX and JSON documentation from the documentation comments. Documentation comments are part of the abstract syntax tree and can be extracted using macros.

## Documentation of the module *ReSTructuredText* and **MarkDown**
# This is a comment, but it is not a documentation comment.

type Kitten = object  ## Documentation of type
  age: int  ## Documentation of field

proc purr(self: Kitten) =
  ## Documentation of function
  echo "Purr Purr"  # This is a comment, but it is not a documentation comment.

# This is a comment, but it is not a documentation comment.

OCaml

OCaml supports nestable comments. For exmaple:

codeLine(* comment level 1(*comment level 2*)*)

Pascal, Delphi

In Pascal and Delphi, comments are delimited by '{ ... }'. Comment lines can also start with '\\' . As an alternative, for computers that do not support these characters, '(* ... *)' are allowed. In Niklaus Wirth's more modern family of languages (including Modula-2 and Oberon), comments are delimited by '(* ... *)'. Comments can be nested. // can be included in a {} and {} can be included in a (**). For example:

(* test diagonals *)
columnDifference := testColumn - column;
if (row + columnDifference = testRow) or
    .......

Perl

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

# A simple example
# 
my $s = "Wikipedia"; # Sets the variable s to "Wikipedia".
print $s . "\n";     # Add a newline character after printing

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

=item Pod::List-E<gt>new()

Create a new list object. Properties may be specified through a hash
reference like this:

  my $list = Pod::List->new({ -start => $., -indent => 4 });

See the individual methods/properties for details.

=cut

sub new {
    my $this = shift;
    my $class = ref($this) || $this;
    my %params = @_;
    my $self = {%params};
    bless $self, $class;
    $self->initialize();
    return $self;
}

R

R only supports inline comments started by the hash (#) character.

# This is a comment
print("This is not a comment")  # This is another comment

Raku

Raku (previously called Perl 6) uses the same line comments and POD Documentation comments as regular Perl (see Perl section above), but adds a configurable block comment type: "multi-line / embedded comments".

These start with a hash character, followed by a backtick, and then some opening bracketing character, and end with the matching closing bracketing character. The content can not only span multiple lines, but can also be embedded inline.

#`{{ "commenting out" this version 
toggle-case(Str:D $s)

Toggles the case of each character in a string:

  my Str $toggled-string = toggle-case("mY NAME IS mICHAEL!");

}}

sub toggle-case(Str:D $s) #`( this version of parens is used now ){
    ...
}

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.

Starting in PHP 8, the # sign can only mean a comment if it's not immediately followed by '['. Otherwise, it will mean a function attribute, which runs until ']':

/**
 * This class contains a sample documentation.
 * 
 * @author Unknown
 */
#[Attribute]
class MyAttribute {
    const VALUE = 'value';
    // This is an inline comment. It starts with '//', like in C++.
    private $value;
    # This is a Unix-style inline comment, which starts with '#'.
    public function __construct($value = null) {
        $this->value = $value;
    }
    /*
    This is a multiline comment.

    These comments cannot be nested.
    */

}

PowerShell

Comments in Windows PowerShell

# Single line comment
Write-Host "Hello, World!"

<# Multi
   Line
   Comment #>

Write-Host "Goodbye, world!"

Python

Line comments in Python are delimiated by the hash (#) character. For example:

# This program prints "Hello World" to the screen
print("Hello World!")  # Note the new syntax

Python does not provide for block comments but a bare string literal represented by a triple-quoted string can be and often is used for this purpose. In the examples below, the triple double-quoted strings act like comments, but are also treated as docstrings:

"""
Assuming this is file mymodule.py, then this string, being the
first statement in the file, will become the "mymodule" module's
docstring when the file is imported.
"""

class MyClass:
    """The class's docstring"""

    def my_method(self):
        """The method's docstring"""

def my_function():
    """The function's docstring"""

Ruby

Inline comments in Ruby start with the # character.

To create a multiline comment, one must place "=begin" at the start of a line, and then everything until "=end" that starts a line is ignored. Including a space after the equals sign in this case throws a syntax error.

puts "This is not a comment"

# this is a comment

puts "This is not a comment"

=begin

whatever goes in these lines

is just for the human reader

=end

puts "This is not a comment"

SQL

Standard comments in SQL are in single-line-only form, using two dashes:

-- This is a single line comment
-- followed by a second line
SELECT COUNT(*)
       FROM Authors
       WHERE Authors.name = 'Smith'; -- Note: we only want 'smith'
                                     -- this comment appears after SQL code

Alternatively, a comment format syntax identical to the "block comment" style used in the syntax for C and Java is supported by Transact-SQL, MySQL, SQLite, PostgreSQL, and Oracle.

MySQL also supports comments from the hash (#) character to the end of the line.

Swift

In Swift, line comments begin //. Block comments are delimited by /*(/*) and */. For example:

// This is a comment.
/* This is also a comment
 but is written over multiple lines. */

Block comments can be nested. For example:

/* This is the start of the outer comment.
    /* This is the nested comment. */
This is the end of the outer comment. */

XML and HTML

A block comment in XML and HTML is delimited by <!-- and -->. Line comment is not supported. For example,

<!-- select the context here -->
<param name="context" value="public" />

For compatibility with SGML, double-hyphen (--) is not allowed inside comments.

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.

See also

• Docstring, a specific type of comment that is parsed and retained throughout the runtime of the program.
• Shebang, the use of #! as an interpreter directive in scripts on Unix-like systems
• HTML comment tag
• Literate programming, alternative documentation paradigm
• Syntax of comments in various programming languages
• COMMENT (CONFIG.SYS directive)
• REM (CONFIG.SYS directive)

Further reading

• Movshovitz-Attias, Dana and Cohen, William W. (2013) Natural Language Models for Predicting Programming Comments. In Association for Computational Linguistics (ACL), 2013.

External links

• How to Write Comments by Denis Krukovsky
• Source Code Documentation as a Live User Manual by PTLogica
• How to Write Comments for the Javadoc Tool