So you downloaded Natural Docs, you figured out the command line, and now it’s time to start documenting your code.  Natural Docs tries to make this very straightforward and painless, so let’s just dive right in:

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

That’s all you need.  Run Natural Docs and here’s what appears in your output:

Okay, so that’s all you need, but probably not all you want.  After all, you’ve got some real functions to document, not little one-liners.  Here’s something more elaborate:

/*
   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;  };

Still not too scary, huh?  Notice the comments are just as readable as the output.  No tags littered about, and the structure is very natural.  You probably get it just by looking at it, but let’s go through the details anyway.

Function: Multiply

Every one of these comments you write (called topics) are going to start with a topic line in the format “keyword: title”.  There are a lot of keywords, but they’re exactly what you’d expect: Function, Class, Variable, etc.  There are also a lot of synonyms so instead of Function you could use Func, Procedure, Proc, Method, Constructor, etc.  It’s designed so you can just use whatever it is you’re describing without memorizing anything.  You can glance over the keyword list but you shouldn’t have to consult it very often.

The other part of the topic line is the title.  It should match whatever it is you’re documenting, in this case the function name Multiply.  Natural Docs is case sensitive even if your programming language isn’t, so make sure you match it closely or you might not get the prototype in your output, which is the little gray box.  You don’t need to include the parameters in the title.  In fact, it’s better if you don’t.

Parameters:

Returns:

See Also:

You can also define headings by skipping a line and ending the text with a colon.  If you’re used to other documentation systems you may think there’s only a handful of headings to choose from, but any text formatted this way will become one.  If you want a heading called Dependencies you can go right ahead and add it.

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

This is what’s called a definition list.  You can use more than one line to finish the definition, as it won’t stop until you skip a line.

x - The first integer.
y - The second integer with a long description.
    This is still part of the description.

This is a new paragraph because we skipped a line.

Indentation doesn’t matter either, so even if the second description line wasn’t indented to match the first, it would still be considered part of it.

<Divide>

This is how we link in Natural Docs, with angle brackets.  There will be a lot more to say about this later, but for now I’ll just show you something cool.  Hover over it in the output below:

You get that everywhere in your generated documentation.

So that’s good for our one function of questionable usefulness, but what if we have a whole class of questionable usefulness?  We can document the class and it’s members the same way we documented the individual function, with a Natural Docs comment right above each element.  We’ll go back to short descriptions to keep the example manageable.

/*
   Class: Counter
   A class that manages an incrementing counter.
*/
class Counter
   {
   public:

      /*
         Constructor: Counter
         Initializes the object.
      */
      Counter()
         {  value = 0;  };

      /*
         Function: Value
         Returns the value of the counter.
      */
      int Value()
         {  return value;  };

      /*
         Function: Increment
         Adds one to the counter.
      */
      void Increment()
         {  value++;  };

   protected:

      /*
         Variable: value
         The counter's value.
      */
      int value;
   };

Everything’s the same, we just substituted Class and Variable for the Function keyword when it was appropriate.  We also used Constructor, but we could have just as easily used Function there too.  They’re both keywords for the same thing so it doesn’t matter.

Like the source code itself, Natural Docs topics have scope.  Value and Increment are seen as part of class Counter, just like they are in the code.  Why is this important?  Linking.  Linking from one topic to another has similar rules to how one function can call another.  Since Value is in the same class as Increment, it’s topic can link to it with just <Increment>.  However, linking to Increment from a different class would require <Counter.Increment> instead.  You can actually use any of the three most common class/member notations: <Counter.Increment>, <Counter::Increment>, and <Counter->Increment>.

If your programming language has full language support, the scope is determined by the code and applied automatically.  However, if you only have basic language support it follows these rules:

• Any topic that appears under a Class topic (or anything that says Starts Scope) is part of that class.
• Any topic that appears under a Section topic (or anything that says Ends Scope) is global again.
• Any File topic (or anything that says Always Global) is global no matter what and doesn’t affect any other topics.

Chances are you would have written the same thing even if you didn’t know this and it would have just worked.  You usually won’t need to think about them at all.  However, it’s still good to be aware of them in case something doesn’t behave the way you expected it to.

You actually know enough to go start documenting now.  I know Mr. ScrollBar says there’s more on this page you can learn, but if you want to skip out early, you can.  Really.  I don’t mind.

Okay then.  On we go.

The syntax for these three is exactly what you would expect it to be.

*Bold text*

_Underlined text_

Paragraphs are broken by skipping lines.  So the two
lines above each have their own paragraph, but these
three lines are all part of the same one.

When underlining multiple words, you can use an underscore for each space or only put them at the edges like we did above.  Both ways will work.

You can add bullet lists by starting a line with a dash, an asterisk, an o, or a plus.  Like definition lists, bullets can span multiple lines and indentation doesn’t matter.  To end a bullet you have to skip a line before doing something else.

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

Some text after the bullet list.

You can add example code or text diagrams by starting each line with >, |, or :.

> a = b + c;
> b++;

a = b + c;
b++;

If you have a long stretch, you can use (start code) and (end) instead.

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

As I mentioned before, we don’t want you to worry about memorizing minor details, so in that spirit it will also accept begin for start and finish or done for end.  You can also write (end code) instead of just (end).

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, or if you put it in a paragraph it will appear after it using the file name as a caption.

This is the first paragraph.

(see logo.gif)

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

This is the first paragraph.

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

logo

The image file names are relative to the source file the comment appears in, so if your file is C:\Project\SourceFile.cpp and your image is C:\Project\Images\Logo.gif, you would write (see Images/Logo.gif).  However, you can also specify image directories in the command line with -img, so if all your source files are in C:\Project\Source and all your images are in C:\Project\Images, you can put “-img C:\Project\Images” on the command line and just use (see logo.gif) again.

Yes, there’s still more to linking.  You can link to URLs and e-mail addresses, but in this case the angle brackets are optional.

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

E-mail addresses are protected from spam crawlers.  They look and act like regular links (try it above) but you can see the actual HTML that’s generated for them here.

As for regular links, to help them fit into sentences easily you can actually 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.

Sometimes you want to include documentation that doesn’t correspond directly to a code element.  Maybe you want to include license information or architecture notes.  There are two ways to do this.

Just because most of the things you write will directly correspond to an element of your source code doesn’t mean they have to.  You can pick any of the available keywords and create a freestanding comment with it.  For example:

/*
   Class: Counter
   A class that manages an incrementing counter.
*/
class Counter
   {
   public:

      /*
         About: License
         This file is licensed under the GPL.
      */

      /*
         Constructor: Counter
         Initializes the object.
      */
      Counter()
         {  value = 0;  };
   ...

The extra license topic will be added to the output just like the functions.

Remember that because of scope, the License topic will actually be considered part of Counter the way it’s listed above.  You’d link to it from outside Counter with <Counter.License>.  That idea may take some getting used to, but if an extra topic only applies to one class that’s actually the most appropriate way to do it.  In this case it’s a license, so if it applies to the entire project instead you could put the comment above the class to make it global, just like moving a function there would.

You can also add additional documentation with text files.  If you put a file with a .txt extension in your source tree and start it with a topic line, it’s contents will be treated the same as if it were in a comment in your source code.  That means you can define multiple topics within it, you can link between them and topics in your source code, and you can use all available formatting options.

Title: License

This file is licensed under the GPL.

I can link to <Counter> and <Counter.Increment>, and
the documentation in that class can even link back
with <License>.


About: Second Topic

I can create a *second* topic in here too, complete
with formatting.

The thing some people forget though is that you must start it with a topic line, like “Title: License” above.  This is how Natural Docs tells it apart from regular text files.

Here’s another useful thing you may want to know about.  Suppose you have a lot of little things to document, like constants.  Writing a separate topic for each one can be very tedious, no matter how much you compress it:

// Constant: COUNTER_NORMAL
// Causes the counter to increment normally.
#define COUNTER_NORMAL 0

// Constant: COUNTER_ODD
// Causes the counter to only increment in odd numbers.
#define COUNTER_ODD 1

// Constant: COUNTER_EVEN
// Causes the counter to only increment in even numbers.
#define COUNTER_EVEN 2

One thing you may have noticed in the keyword list is that they almost all have plural forms.  These are used to create what are called list topics.  You define a topic using a plural keyword, and then anything appearing in a definition list within it creates a linkable symbol as if they each had their own topic.  For example:

/*
   Constants: Counter Modes

   COUNTER_NORMAL - Causes the counter to increment normally.
   COUNTER_ODD    - Causes the counter to only increment in odd numbers.
   COUNTER_EVEN   - Causes the counter to only increment in even numbers.
*/
#define COUNTER_NORMAL 0
#define COUNTER_ODD 1
#define COUNTER_EVEN 2

I would now be able to write <COUNTER_ODD> and have it work the same as it would with the first example.

Using the enum or enumeration keyword is special because it automatically behaves in a similar manner.  This allows both the enum and its values to be documented in the same place.

/*
   Enum: CounterMode

   NORMAL - Causes the counter to increment normally.
   ODD    - Causes the counter to only increment in odd numbers.
   EVEN   - Causes the counter to only increment in even numbers.
*/
enum CounterMode { NORMAL, ODD, EVEN };

That’s it, you’re done with this walkthrough.  You should know enough now to make very good use of Natural Docs.  If you still want to know more, you can look in the reference for some of the smaller details we may have skipped over.  Also, look at the Customizing pages on this web site for even more you can do.