The flexibility provided by comments allows for a wide degree of variability, but formal conventions for their use are commonly part of programming style guides.
Overview
Comments are generally formatted as either block comments (also called prologue comments or stream comments) or line comments (also called inline comments).[3]
Block comments delimit a region of source code which may span multiple lines or a part of a single line. 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.[4][5][6]
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.[6]
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.[6]
Uses
How best to make use of comments is subject to dispute; different commentators have offered varied and sometimes opposing viewpoints.[7][8] There are many different ways of writing comments and many commentators offer conflicting advice.[8]
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.
/* 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]);}
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.
"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."[10]
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:
' 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")
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.[11]
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:
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);
Resource inclusion
Logos, diagrams, and flowcharts consisting of ASCII art constructions can be inserted into source code formatted as a comment.[12] 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 XMLCDATA section, which is technically considered distinct from comments, but can serve similar purposes.[13]
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.[13]
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.
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.
Programming tools sometimes store documentation and metadata in comments.[14] These may include insert positions for automatic header file inclusion, commands to set the file's syntax highlighting mode,[15] or the file's revision number.[16] 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.[17]
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.[20]
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.
Directive uses
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,[21] e.g. Python's PEP 263.[22]
The script below for a Unix-like system shows both of these uses:
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){caseCMD_SHOW_HELP_AND_EXIT:do_show_help();/* Fall thru */caseCMD_EXIT:do_exit();break;caseCMD_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".[23]
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:
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.[24] The occurrence of this phenomenon can be easily seen from online resources that track profanity in source code.[25]
Normative views
There are various normative views and long-standing opinions regarding the proper use of comments in source code.[26][27] Some of these are informal and based on personal preference, while others are published or promulgated as formal guidelines for a particular community.[28]
Need for comments
Experts have varying viewpoints on whether, and when, comments are appropriate in source code.[9][29] 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.[9] 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).[30][31]
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.[32][33]
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:
Strings="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."[10] Further, for professional coding environments, the level of detail is ordinarily well defined to meet a specific performance requirement defined by business operations.[31]
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.[34]
Block comment
The following code fragments in C demonstrate just a tiny example of how comments can vary stylistically, while still conveying the same basic information:
/* This is the comment body. Variation One.*/
/***************************\* ** This is the comment body. ** Variation Two. ** *\***************************/
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[35] is one expert who advocates aligning the left edges of comments:[36]
/* 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. */
The use of /* and */ as block comment delimiters was inherited from PL/I into the B programming language, the immediate predecessor of the C programming language.[37]
Line comments
Line comments generally use an arbitrary delimiter or sequence of tokens to indicate the beginning of a comment, and a newline character to indicate the end of a comment.
In this example, all the text from the ASCII characters // to the end of the line is ignored.
// -------------------------// This is the comment body.// -------------------------
Often such a comment has to begin at far left and extend to the whole line. However, in many languages, it is also possible to put a comment inline with a command line, to add a comment to it – as in this Perl example:
print$s."\n";# Add a newline character after printing
If a language allows both line comments and block comments, programming teams may decide upon a convention of using them differently: e.g. line comments only for minor comments, and block comments to describe higher-level abstractions.
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 Unixgrep utility or even syntax-highlighted within text editors. These are sometimes referred to as "codetags"[38][39] or "tokens", and the development tools might even assist you in listing all of them.[40]
Such tags differ widely, but might include:
BUG, DEBUG — a known bug that should be corrected.
FIXME — should be corrected.
HACK, BODGE, KLUDGE — a workaround.
TODO — something to be done.
NOTE — used to highlight especially notable gotchas.
UNDONE — a reversal or "roll back" of previous code.
XXX — warn other programmers of problematic or misguiding code
Typographic conventions to specify comments vary widely. Further, individual programming languages sometimes provide unique variants.
Ada
The Ada programming language uses '--' to indicate a comment up to the end of the line.
For example:
-- the air traffic controller task takes requests for takeoff and landingtasktypeController(My_Runway: Runway_Access)is-- task entries for synchronous message passingentryRequest_Takeoff(ID: inAirplane_ID;Takeoff: outRunway_Access);entryRequest_Approach(ID: inAirplane_ID;Approach: outRunway_Access);endController;
APL
APL uses ⍝ to indicate a comment up to the end of the line.
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
This section of AppleScript code shows the two styles of comments used in that language.
(*This program displays a greeting.*)ongreet(myGreeting)display dialogmyGreeting&" world!"endgreet-- Show the greetinggreet("Hello")
BASIC
In this classic early BASIC code fragment the REM ("Remark") keyword is used to add comments.
10REM This BASIC program shows the use of the PRINT and GOTO Statements.15REM It fills the screen with the phrase "HELLO"20PRINT"HELLO"30GOTO20
PublicClassForm1PrivateSubButton1_Click(senderAsObject,eAsEventArgs)HandlesButton1.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 greetingEndSubEndClass
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.
/* * 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))gotobad_fork_free;
Since C99, it has also been possible to use the // syntax from C++, indicating a single-line comment.
The availability of block comments allows for marking structural breakouts, i.e. admissible violations of the single-entry/single-exit rule of Structured Programming, visibly, like in the following example:
staticEdgeedge_any(Noden,Nodem){// Returns whether any edge is between nodes $n and $m.Edgee;for(e=n->edges;e;e=e->next){if(e->dst==m){/*********/returne;}}for(e=m->edges;e;e=e->next){if(e->dst==n){/*****/break;}}returne;}
In many languages lacking a block comment, e.g. awk, you can use sequences of statement separators like ; instead. But it's impossible in languages using indentation as a rigid indication of intended block structure, like Python.
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.[41][42]
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.
CC Lines that begin with 'C' (in the first or 'comment' column) are commentsCWRITE(6,610) 610FORMAT(12HHELLOWORLD)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_testprint'(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 commenton more lines -}-- and this is a comment on one lineputStrLn"Wikipedia"-- this is another comment
Haskell also provides a literate programming method of commenting known as "Bird Style".[43] 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> fact0=1> fact(n+1)=(n+1)*factn 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:
% the LaTeX source file The \verb|fact n| function call computes $n!$ if $n\ge0$, here is a definition:\\\begin{code}fact::Integer->Integerfact0=1fact(n+1)=(n+1)*factn\end{code} Here more explanation using \LaTeX{} markup
Java
This Java code fragment shows a block comment used to describe the setToolTipText method. The formatting is consistent with Sun MicrosystemsJavadoc standards. The comment is designed to be read by the Javadoc processor.
/** * 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. */publicvoidsetToolTipText(Stringtext){// 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 commentvariNum=100;variTwo=2;// A comment at the end of line/*multi-lineJavaScript comment*/
Lua
The Lua programming language 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-linelong comment]]print(20)-- print the result
A common technique to comment out a piece of code,[44] is to enclose the code between --[[ and --]], as below:
--[[print(10)--]]-- no action (commented out)
In this case, it's possible to reactivate the code by adding a single hyphen to the first line:
---[[print(10)--]]--> 10
In the first example, 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 --.
Long comments in Lua can be more complex than these, as you can read in the section called "Long strings" c.f. Programming in Lua.
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 termd=[0-10];%{ %{ (Example of a nested comment, indentation is for cosmetics (and ignored).) %}Weformthesequence,followingtheTaylorformula.Notethatwe'reoperatingonavector.%}seq=d.*(x-c).^n./(factorial(n))% We add-up to get the Taylor approximationapprox=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.[45]
## Documentation of the module *ReSTructuredText* and **MarkDown**# This is a comment, but it is not a documentation comment.typeKitten=object## Documentation of typeage:int## Documentation of fieldprocpurr(self:Kitten)=## Documentation of functionecho"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 uses nestable comments, which is useful when commenting a code block.
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.[46]
=item Pod::List-E<gt>new()Create a new list object. Properties may be specified through a hashreference like this: my $list = Pod::List->new({ -start => $., -indent => 4 });See the individual methods/properties for details.=cutsubnew{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 commentprint("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".[51]
These start with a hash character, followed by a backtick, and then some opening bracketing character, and end with the matching closing bracketing character.[51] 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!");}}subtoggle-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]classMyAttribute{constVALUE='value';// This is an inline comment. It starts with '//', like in C++.private$value;# This is a Unix-style inline comment, which starts with '#'.publicfunction__construct($value=null){$this->value=$value;}/* This is a multiline comment. These comments cannot be nested. */}
# Single line commentWrite-Host"Hello, World!"<# Multi Line Comment #>Write-Host"Goodbye, world!"
Python
Inline comments in Python use the hash (#) character, as in the two examples in this code:
# This program prints "Hello World" to the screenprint("Hello World!")# Note the new syntax
Block comments, as defined in this article, do not technically exist in Python.[52] A bare string literal represented by a triple-quoted string can be used,[53] but is not ignored by the interpreter in the same way that "#" comment is.[52] In the examples below, the triple double-quoted strings act in this way as comments, but are also treated as docstrings:
"""Assuming this is file mymodule.py, then this string, being thefirst statement in the file, will become the "mymodule" module'sdocstring when the file is imported."""classMyClass:"""The class's docstring"""defmy_method(self):"""The method's docstring"""defmy_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 commentputs"This is not a comment"=beginwhatever goes in these linesis just for the human reader=endputs"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 lineSELECTCOUNT(*)FROMAuthorsWHEREAuthors.name='Smith';-- Note: we only want 'smith'-- this comment appears after SQL code
MySQL also supports comments from the hash (#) character to the end of the line.
Swift
Single-line comments begin with two forward-slashes (//):
// This is a comment.
Multiline comments start with a forward-slash followed by an asterisk (/*) and end with an asterisk followed by a forward-slash (*/):
/* This is also a comment but is written over multiple lines. */
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:
/* This is the start of the first multiline comment. /* This is the second, nested multiline comment. */ This is the end of the first multiline comment. */
and can spread over several lines until the terminator,
-->
For example,
<!-- select the context here --><paramname="context"value="public"/>
For compatibility with SGML, the string "--" (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.[59]
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
↑ Source code can be divided into program code (which consists of machine-translatable instructions); and comments (which include human-readable notes and other kinds of annotations in support of the program code).Penny Grubb, Armstrong Takang (2003). Software Maintenance: Concepts and Practice. World Scientific. pp.7, plese start120–121. ISBN978-981-238-426-3.
↑ For purposes of this article, programming language comments are treated as indistinct from comments that appear in markup languages, configuration files and other similar contexts. Moreover, markup language is often closely integrated with programming language code, especially in the context of code generation. See e.g., Ganguli, Madhushree (2002). Making Use of Jsp. New York: Wiley. ISBN978-0-471-21974-3., Hewitt, Eben (2003). Java for Coldfusion Developers. Upper Saddle River: Pearson Education. ISBN978-0-13-046180-3.
↑ Dixit, J.B. (2003). Computer Fundamentals and Programming in C. Laxmi Publications. ISBN978-81-7008-882-0.
↑ W. R., Dietrich (2003). Applied Pattern Recognition: Algorithms and Implementation in C++. Springer. ISBN978-3-528-35558-6. offers viewpoints on proper use of comments in source code. p. 66.
1 2 Keyes, Jessica (2003). Software Engineering Handbook. CRC Press. ISBN978-0-8493-1479-7. discusses comments and the "Science of Documentation" p. 256.
1 2 Niederst, Jennifer (2006). Web Design in a Nutshell: A Desktop Quick Reference. O'Reilly. ISBN978-0-596-00987-8.Sometimes the difference between a "comment" and other syntax elements of a programming or markup language entails subtle nuances. Niederst indicates one such situation by stating: "Unfortunately, XML software thinks of comments as unimportant information and may simply remove the comments from a document before processing it. To avoid this problem, use an XML CDATA section instead."
↑ Morelli, Ralph (2006). Java, Java, Java: object-oriented problem solving. Prentice Hall College. ISBN978-0-13-147434-5.
1 2 "How to Write Doc Comments for the Javadoc Tool". Retrieved 2007-07-24. Javadoc guidelines specify that comments are crucial to the platform. Further, the appropriate level of detail is fairly well-defined: "We spend time and effort focused on specifying boundary conditions, argument ranges and corner cases rather than defining common programming terms, writing conceptual overviews, and including examples for developers."
↑ Yourdon, Edward (2007). Techniques of Program Structure and Design. University of Michigan. 013901702X.Non-existent comments can make it difficult to comprehend code, but comments may be detrimental if they are obsolete, redundant, incorrect or otherwise make it more difficult to comprehend the intended purpose for the source code.
↑ Dewhurst, Stephen C (2002). C++ Gotchas: Avoiding Common Problems in Coding and Design. Addison-Wesley Professional. ISBN978-0-321-12518-7.
1 2 "Python 3 Basic Syntax". Archived from the original on 19 August 2021. Retrieved 25 February 2019. Triple quotes are treated as regular strings with the exception that they can span multiple lines. By regular strings I mean that if they are not assigned to a variable they will be immediately garbage collected as soon as that code executes. hence are not ignored by the interpreter in the same way that #a comment is.
An integrated development environment (IDE) is a software application that provides comprehensive facilities for software development. An IDE normally consists of at least a source-code editor, build automation tools, and a debugger. Some IDEs, such as IntelliJ IDEA, Eclipse and Lazarus contain the necessary compiler, interpreter or both; others, such as SharpDevelop and NetBeans, do not.
Java is a high-level, class-based, object-oriented programming language that is designed to have as few implementation dependencies as possible. It is a general-purpose programming language intended to let programmers write once, run anywhere (WORA), meaning that compiled Java code can run on all platforms that support Java without the need to recompile. Java applications are typically compiled to bytecode that can run on any Java virtual machine (JVM) regardless of the underlying computer architecture. The syntax of Java is similar to C and C++, but has fewer low-level facilities than either of them. The Java runtime provides dynamic capabilities that are typically not available in traditional compiled languages.
Programming style, also known as coding style, refers to the conventions and patterns used in writing source code, resulting in a consistent and readable codebase. These conventions often encompass aspects such as indentation, naming conventions, capitalization, and comments. Consistent programming style is generally considered beneficial for code readability and maintainability, particularly in collaborative environments.
A string literal or anonymous string is a literal for a string value in the source code of a computer program. Modern programming languages commonly use a quoted sequence of characters, formally "bracketed delimiters", as in x = "foo", where, "foo" is a string literal with value foo. Methods such as escape sequences can be used to avoid the problem of delimiter collision and allow the delimiters to be embedded in a string. There are many alternate notations for specifying string literals especially in complicated cases. The exact notation depends on the programming language in question. Nevertheless, there are general guidelines that most modern programming languages follow.
In computer programming, indentation style is a convention, a.k.a. style, governing the indentation of blocks of source code. An indentation style generally involves consistent width of whitespace before each line of a block, so that the lines of code appear to be related, and dictates whether to use space or tab characters for the indentation whitespace.
YAML is a human-readable data serialization language. It is commonly used for configuration files and in applications where data is being stored or transmitted. YAML targets many of the same communications applications as Extensible Markup Language (XML) but has a minimal syntax that intentionally differs from Standard Generalized Markup Language (SGML). It uses Python-style indentation to indicate nesting and does not require quotes around most string values.
Doxygen is a documentation generator and static analysis tool for software source trees. When used as a documentation generator, Doxygen extracts information from specially-formatted comments within the code. When used for analysis, Doxygen uses its parse tree to generate diagrams and charts of the code structure. Doxygen can cross reference documentation and code, so that the reader of a document can easily refer to the actual code.
A delimiter is a sequence of one or more characters for specifying the boundary between separate, independent regions in plain text, mathematical expressions or other data streams. An example of a delimiter is the comma character, which acts as a field delimiter in a sequence of comma-separated values. Another example of a delimiter is the time gap used to separate letters and words in the transmission of Morse code.
Code or text folding, or less commonly holophrasting, is a feature of some graphical user interfaces that allows the user to selectively hide ("fold") or display ("unfold") parts of a document. This allows the user to manage large amounts of text while viewing only those subsections that are currently of interest. It is typically used with documents which have a natural tree structure consisting of nested elements. Other names for these features include expand and collapse, code hiding, and outlining. In Microsoft Word, the feature is called "collapsible outlining".
Plain Old Documentation (pod) is a lightweight markup language used to document the Perl programming language as well as Perl modules and programs.
In computer programming, a directive or pragma is a language construct that specifies how a compiler should process its input. Depending on the programming language, directives may or may not be part of the grammar of the language and may vary from compiler to compiler. They can be processed by a preprocessor to specify compiler behavior, or function as a form of in-band parameterization.
Javadoc is a documentation generator created by Sun Microsystems for the Java language for generating API documentation in HTML format from Java source code. The HTML format is used for adding the convenience of being able to hyperlink related documents together.
In computing, a here document is a file literal or input stream literal: it is a section of a source code file that is treated as if it were a separate file. The term is also used for a form of multiline string literals that use similar syntax, preserving line breaks and other whitespace in the text.
An INI file is a configuration file for computer software that consists of plain text with a structure and syntax comprising key–value pairs organized in sections. The name of these configuration files comes from the filename extension INI, short for initialization, used in the MS-DOS operating system which popularized this method of software configuration. The format has become an informal standard in many contexts of configuration, but many applications on other operating systems use different file name extensions, such as conf and cfg.
The syntax of the Python programming language is the set of rules that defines how a Python program will be written and interpreted. The Python language has many similarities to Perl, C, and Java. However, there are some definite differences between the languages. It supports multiple programming paradigms, including structured, object-oriented programming, and functional programming, and boasts a dynamic type system and automatic memory management.
This comparison of programming languages compares the features of language syntax (format) for over 50 computer programming languages.
Coding conventions are a set of guidelines for a specific programming language that recommend programming style, practices, and methods for each aspect of a program written in that language. These conventions usually cover file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, programming rules of thumb, architectural best practices, etc. These are guidelines for software structural quality. Software programmers are highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier. Coding conventions are only applicable to the human maintainers and peer reviewers of a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows, or may be as informal as the habitual coding practices of an individual. Coding conventions are not enforced by compilers.
JSDoc is a markup language used to annotate JavaScript source code files. Using comments containing JSDoc, programmers can add documentation describing the application programming interface of the code they're creating. This is then processed, by various tools, to produce documentation in accessible formats like HTML and Rich Text Format. The JSDoc specification is released under CC BY-SA 3.0, while its companion documentation generator and parser library is free software under the Apache License 2.0.
LOLCODE is an esoteric programming language inspired by lolspeak, the language expressed in examples of the lolcat Internet meme. The language was created in 2007 by Adam Lindsay, a researcher at the Computing Department of Lancaster University.
PL/SQL is Oracle Corporation's procedural extension for SQL and the Oracle relational database. PL/SQL is available in Oracle Database, TimesTen in-memory database, and IBM Db2. Oracle Corporation usually extends PL/SQL functionality with each successive release of the Oracle Database.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
