Documentation Team/API Documentation: Difference between revisions
m DevelopmentTeam/Tutorials/API Documentation moved to DocumentationTeam/API Documentation: API documentation is significant enough to warrant a place in the doc team root. |
m categorize |
||
| (4 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{draft}} | <noinclude>[[Category:API]] | ||
[[Category:Documentation]] | |||
</noinclude>{{draft}} | |||
== Definition == | == Definition == | ||
| Line 149: | Line 151: | ||
'''4. Write a main page for your application.''' | '''4. Write a main page for your application.''' | ||
This is usually done in a separate file | This is usually done in a separate file in the top-level of a library or application. The file's content is just a single apidox comment that starts with /** @mainpage title ; the rest of the file is just a long comment about what the library or application is for. | ||
== Fixing APIDOX in Old Code == | == Fixing APIDOX in Old Code == | ||
| Line 380: | Line 382: | ||
Very useful, in fact, for the reader who is wondering | Very useful, in fact, for the reader who is wondering | ||
how exactly to use the class in a straightforward way. | how exactly to use the class in a straightforward way. | ||
Most classes | Most classes have example code. | ||
One way to write example code is to use @code and @endcode around | One way to write example code is to use @code and @endcode around | ||
| Line 396: | Line 398: | ||
</code> | </code> | ||
This is how most of the examples | This is how most of the examples | ||
are done, actually. It works reasonably well, you can pare the | are done, actually. It works reasonably well, you can pare the | ||
example down to something really minimal and leave out all the | example down to something really minimal and leave out all the | ||
| Line 425: | Line 427: | ||
:This is a list of all available documentation tags of doxygen, from the official site. Note that the list uses a backslash in front of a tag, while this page always used the at sign. Both are allowed, but for KDE you should use the at sign to stay consistent within KDE. | :This is a list of all available documentation tags of doxygen, from the official site. Note that the list uses a backslash in front of a tag, while this page always used the at sign. Both are allowed, but for KDE you should use the at sign to stay consistent within KDE. | ||
--> | --> | ||