You document your code by putting Natural Docs content in the comments or in text files.  Before we go through all the specifics, here’s an example right off the bat so you have an idea of what it looks like.  Here’s your code:

/*
   Function: Multiply
   Multiplies two integers and returns the result.
*/
int Multiply (int x, int y)
   {  return x * y;  };

And here’s what appears in your output:

Here’s a more elaborate example.  This is overkill for this particular function, but you get the idea.

/*
   Function: Multiply

   Multiplies two integers.

   Parameters:

      x - The first integer.
      y - The second integer.

   Returns:

      The two integers multiplied together.

   See Also:

      <Divide>
*/
int Multiply (int x, int y)
   {  return x * y;  };

Not too scary, huh?  Notice the comments are just as readable as the output.  No tags littered about, and the structure is very natural.  This was one of the goals of Natural Docs.  Anyway, on to the details.

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 line comments strung together.  The only requirement is that the comments are alone on a line.  Comments appearing on the same lines as code are ignored.

/* 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 or how thick the lines are.  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.  
//                                                            
//////////////////////////////////////////////////////////////

Perl users can use POD to do block comments.

=begin nd

Function: Multiply
Multiplies two integers and returns the result.

=cut


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

Important:  The second form of just =nd is offered as a convenience but 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.

Alternately, documentation can be included in text files.  Any file with a .txt extension appearing in the source tree will be scanned for Natural Docs topics.  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.

Note that you still need to include topic headers, though.  Anything before the first header will be ignored, and if the file doesn’t have any header lines at all, it will be ignored completely.

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.

As you may have guessed, a topic in Natural Docs starts with a “keyword: name” line.  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 they are.  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 or only have basic language support, scoping follows these basic 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 anything else.

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.

As you saw in the more elaborate example, you can apply additional formatting and layout to your Natural Docs content, all in ways that will appear very natural in the source code.

First of all, you 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.  The first line of the list must be after a blank line or something like a header; it can’t be

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 is a symbol and can be linked to just as if it had its own topic.

Finally, 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 other than any line or text box symbols you may be using with the comment.

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

Linking is the one place where Natural Docs has some negative effect on the readability of the comments.  Of course, the alternative would be to automatically guess where links should be, but systems that do that typically 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 are 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.  Links will try to resolve to globals before relative because not everyone wants to use relative links, and this way they can ignore it without anything getting messed up.

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>

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.

Here’s our overkill example again, just to refresh your memory.  You can see examples of what a complete project’s output would look like on our web site.

Make sure you visit the troubleshooting page if things aren’t working the way you expect them to.

/*
   Function: Multiply

   Multiplies two integers.

   Parameters:

      x - The first integer.
      y - The second integer.

   Returns:

      The two integers multiplied together.

   See Also:

      <Divide>
*/
int Multiply (int x, int y)
   {  return x * y;  };