There is no special comment style for Natural Docs.  You just embed Natural Docs topics into regular comments, and it’s pretty tolerant as far as style goes.  You can use block comments or string together line comments.  The only requirement is that the comments are not on the same line as code.

/* Function: Multiply
   Multiplies two integers and returns the result. */

// Function: Multiply
// Multiplies two integers and returns the result.

Note that when stringing line comments together, blank lines that you want to include in the documentation must start with the comment symbol as well.  If a line is completely blank, it’s considered the end of the comment and thus the end of the Natural Docs topic.

Natural Docs can also handle comment boxes and horizontal lines.  It doesn’t matter what symbols they use.  The boxes don’t need to be closed on the right side, and they can have different symbols for the edges and corners.

/*
 * Function: Multiply
 * Multiplies two integers and returns the result.
 */

/* +-------------------------------------------------+
   | Function: Multiply                              |
   | Multiplies two integers and returns the result. |
   +-------------------------------------------------+ */

//////////////////////////////////////////////////////////////
//
//  Function: Multiply
//  ------------------
//
//  Multiplies two integers together and returns the result.
//
//////////////////////////////////////////////////////////////

If you have full language support, you can also use Javadoc-style comments to write Natural Docs documentation.  To do this you repeat the last symbol on the first line of the comment once.  The comment must appear directly above what it’s documenting, and you can omit the topic line if you want (the “Function: Multiply” part.)

/**
 * Multiplies two integers and returns the result.
 */

///
// Multiplies two integers together and returns the result.

If you omit the topic line and include any Javadoc tags in the comment, like @param, the entire comment will be treated as Javadoc and can only use Javadoc formatting.  Otherwise it’s treated as a Natural Docs comment and you can use all the formatting options described on this page.  You can have both styles in the same source file, but not in the same comment.

Perl users can also use POD to do block comments.

=begin nd

Function: Multiply
Multiplies two integers and returns the result.

=cut

You can also use NaturalDocs or Natural Docs in place of ND.  None of them are case sensitive.  If for some reason you want to go back to POD documentation instead of using =cut, you can write =end nd.

There’s a second form of just =nd which is offered as a convenience.  However, it is not valid POD.  Perl will skip over it and execute fine, but POD parsers will give errors and possibly include the unformatted text in the output.  Use the longer, valid form unless you know for certain that no one will ever try to run POD on your code.

=nd

Function: Multiply
Multiplies two integers and returns the result.

=cut

Documentation can also be included in text files.  Any file with a .txt extension appearing in the source tree and starting with a topic line will included in the documentation.  It will be treated the same as a source file, meaning it will appear in the menu, its topics will be in the indexes, and its topics can be linked to from anywhere in the documentation.  The only difference is you don’t need comment symbols.

Remember that the topic line is required to be the first line of content.  If the first non-blank line is not in the “Function: Multiply” format the file will be ignored.  An easy way to do this is to use the Title keyword, although all of the other ones will work as well.

Title: License

This project is licensed under the GPL.

This method is convenient for documenting file formats, configuration settings, the general program architecture, or anything else that isn’t directly tied to a source file.

A topic in Natural Docs starts with a topic line in the format “keyword: name”.  You can have multiple topics per comment as long as you separate them with a blank line.  The keywords aren’t case sensitive.

The list of keywords is pretty predictable: Function, Class, Variable, etc.  Just use what you’re documenting.  There are many synonyms as well, so you can use keywords like Func, Procedure, Proc, Method and Constructor.  Look at the full list of keywords to see everything that’s available.

The list of keywords is separated into topic types.  Each type gets its own index, and which specific keyword you use doesn’t matter.  Some also have scoping rules or other behavior as noted.

Like the code it’s documenting, Natural Docs topics have scope.  This mostly has to do with linking: if you’re in a class you can link to its members by their name alone, but if you’re not, you have to use a notation like class.member or class::member.

If you have full language support and are documenting something that appears in the code, the scope will be handled automatically.  If you’re using text files, have basic language support, or are including a topic that doesn’t correspond to something in the code, scoping follows these rules:

• Everything after a class topic (or anything that says “Starts Scope”) is part of that class.
• Everything after a section topic (or anything that says “Ends Scope”) is global again.
• File topics (or anything that says “Always Global”) are global but do not change the scope for what follows.

If you looked at the list, you saw that most of the keywords have plural forms.  That’s for list topics, which let you document many small things without using the full syntax.  Anything that appears in definition lists within that topic will be treated as if it had its own topic.  It will appear in the indexes and be linkable, just like normal topics.

Function list topics will automatically break apart in the output as well, so it will look the same as if you documented each one individually.

Linking is the one place where Natural Docs has some negative effect on the readability of the comments.  The alternative would be to automatically guess where links should be, but systems that do that can sometimes pepper your sentences with unintentional links to functions called “is” or “on”.  However, the Natural Docs syntax is still as minimal as possible.  Simply surround any topic you want to link to with angle brackets.  Natural Docs will keep track off all the topics and where they are defined, so you don’t need to use HTML-like syntax or remember what file anything is in.  Also, if the link can’t be resolved to anything, Natural Docs leaves the angle brackets in the output so if something wasn’t intended to be a link (such as #include <somefile.h>) it won’t be mangled.

Let's link to function <Multiply>.

Links and topic names are case sensitive, regardless of whether the language is or not.

When linking to functions, it doesn’t matter if you include empty parenthesis or not.  Both <Function> and <Function()> will work.  However, if you documented the function with parameters as part of the name, you will need to include those parameters whenever linking to it.  It is recommended that you only include parameters in the topic name if you need to distinguish between two functions with the same name.

If the topic has a summary sentence, hovering over the link will give it to you as a tooltip.  If the topic has a prototype, that will be included as well.  You can try it above.

If a topic is considered part of a class, they can be linked to using any of the three most common class/member notations:  class.member, class::member, and class->member.  Natural Docs will not be confused by <class->member>.  Like in the language itself, if the topic you’re writing is in that class’ scope you can link to it simply as <member>.

If you have multi-level classes and packages, links can be relative as well.  So if you’re in Project::UI::Window::Base and you want to link to Project::UI::Button::Base, just using <Button::Base> will work.

To make the documentation easier to write and easier to read in the source file, you can include plurals and possessives inside the angle brackets.  In other words, you don’t have to use awkward syntax like <Object>s, although that’s supported as well.  You can simply write <Objects> and it will link to the symbol Object just fine.  It can handle any plural and/or possessive form you can throw at it.  I’m not kidding: Foxes, Fox’s, Foxes’, Children, Mice, Alumni, Indices, Amoebae, Teeth, just try to trip it up.

You can also link to URLs and e-mail addresses.  It will detect them automatically, but you can also put them in angle brackets if you like.

Visit <http://www.website.com> or send messages to
email@address.com.

E-mail addresses are protected in a way that should avoid spam crawlers.  Although the link above looks and acts like a regular link (try it) the HTML code actually looks like this:

<a href="#"
 onClick="location.href='mai' + 'lto:' + 'em' + 'ail' + '@'
          + 'addre' + 'ss.com'; return false;">
    em<span style="display: none">.nosp@m.</span>ail
    <span>@</span>
    addre<span style="display: none">.nosp@m.</span>ss.com
</a>

You can apply additional formatting and layout to your Natural Docs content, all in ways that will appear very natural in the source code.

You can break paragraphs by leaving blank lines between them.  So we have this in our content:

The first paragraph blah blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah.

The second paragraph blah blah blah blah blah blah blah
blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah.

and we get this in our output:

You can apply bold to a stretch of text by surrounding it with asterisks.  You can apply underlining by surrounding it with underscores instead.  With underlining, it doesn’t matter if you use an underscore for every space between words or not; they’ll be converted to spaces if you do.

Some *bold text* and some _underlined text_
and yet _more_underlined_text_.

You can add headings to your output just by ending a line with a colon and having a blank line above it.

Some text before the heading.

Heading:
Some text under the heading.

You must have a blank line above the heading or it will not work.  You can skip the blank after it but not before.

You can add bullet lists by starting a line with a dash, an asterisk, an o, or a plus.  Bullets can have blank lines between them if you want, and subsequent lines don’t have to be indented.  You end a list by skipping a line and doing something else.

- Bullet one.
- Bullet two.
  Bullet two continued.
- Bullet three.

Some text after the bullet list.

o Spaced bullet one.

o Spaced bullet two.
Spaced bullet two continued.

o Spaced bullet three.

Some text after the spaced bullet list.

You can add a definition list by using the format below, specifically “text space dash space text”.  Like bullet lists, you can have blank lines between them if you want, subsequent lines don’t have to be indented, and you end the list by skipping a line and doing something else.

First  - This is the first item.
Second - This is the second item.
         This is more of the second item.
Third  - This is the third item.
This is more of the third item.

Some text after the definition list.

Remember that with definition lists, if you’re using the plural form of the keywords each entry can be linked to as if it had its own topic.

You can add example code or text diagrams by starting each line with >, |, or :.  If you have a vertical line or text box with the comment, you must separate these symbols from it with a space.

: a = b + c;

>   +-----+     +-----+
>   |  A  | --> |  B  |
>   +-----+     +-----+
>                  |
>               +-----+
>               |  C  |
>               +-----+

a = b + c;

+-----+     +-----+
|  A  | --> |  B  |
+-----+     +-----+
               |
            +-----+
            |  C  |
            +-----+

For long stretches, this may be too tedious.  You can start a code section by placing (start code) or just (code) alone on a line.  You end it with either (end code) or just (end).  You can’t put any other content on these lines.

(start code)

if (x == 0) {
   DoSomething();
}

return x;

(end)

if (x == 0) {
   DoSomething();
}

return x;

You can also use example, diagram, or table instead of code.  Just use whatever’s appropriate.  Always flexible, it will accept begin for start and it will accept finish or done for end so you don’t have to remember the exact word.

You can include images in your documentation by writing “(see filename)”.  If you put it alone on a line it will be embedded in place.

This is the first paragraph.

(see logo.gif)

This is the second paragraph.

This is the first paragraph.

This is the second paragraph.

If it’s not alone on a line the image will appear after the end of the paragraph, the text will become a link to it, and the file name will be used as a caption.

This is the first paragraph (see logo.gif)  This is
more of the first paragraph.

This is the first paragraph (see logo)  This is more of the first paragraph.

logo

The image file names are relative to the source file the comment appears in or any directories specified with the -img command line option.  You can use relative paths like (see images/logo.gif) and (see ../images/logo.gif), but you cannot use absolute paths, URLs, or specify a file that’s not in a folder included by -i or -img.

Natural Docs supports gif, jpg, jpeg, png, and bmp files.

Natural Docs automatically determines the page title as follows:

• If there’s only one topic in the file, that topic’s title becomes the page title.
• Otherwise, if the first topic in the file is a class, section, or file, that topic’s title becomes the page title.
• Otherwise, the file name becomes the page title.

This should be enough for most people.  However, if you don’t like the page title Natural Docs has chosen for you, add a “Title: [name]” comment to the top of the file to override it.  Title is a synonym of Section, so that will satisfy the second rule and make it the page title.

Summaries are automatically generated for every file, class, and section.  You don’t have to do anything special to get them.

There are two things you may want to keep in mind when documenting your code so that the summaries are nicer.  The first is that they use the first sentence in the topic as the description, so long as it’s plain text and not something like a bullet list.  It will also appear in the tooltip whenever that topic is linked to.

The second is that you may want to manually add group topics to divide long lists and make the summaries easier to navigate.  Natural Docs will automatically group them by type if you do not, but sometimes you want to be more specific.  You don’t need to provide a description, just adding a “Group: [name]” comment is sufficient.  Note that once you manually add a group automatic grouping is completely turned off for that class.

Here’s an example summary.  Note that as before, when you hover over a link, you’ll get the prototype and summary line as a tooltip.

If you have full language support Natural Docs will also extract documentation from actual Javadoc comments, not just Natural Docs comments written with the Javadoc comment symbols.  This provides you with a good method of migrating to Natural Docs as you don’t have to convert all of your existing documentation.

/**
 * Multiplies two integers.
 *
 * @param x The first integer.
 * @param y The second integer.
 * @return The two integers multiplied together.
 * @see Divide
 */

While most Javadoc tags and simple HTML formatting are supported, Natural Docs is not a full Javadoc parser and may not support some advanced tags and HTML.  See this page for a list of what’s supported and what isn’t.

A source file can contain both Natural Docs and Javadoc comments.  However, you cannot mix the two within a single comment.  For example, you can’t use asterisks for bold in a @param line.  If a comment is written with the Javadoc comment symbols (repeat the last symbol of the first line once) doesn’t have a topic line (like “Function: Multiply”) and uses Javadoc tags (like @param) the comment is treated as Javadoc.  If any of those conditions aren’t true it’s treated as a Natural Docs comment.