docs/user/apidoc.dox

39 	This section describes formal requirements, such as location and naming of
63 		documentation quicker if they change a method, but as you will see we'll
73 		-# The name of the files is the same as the base of the header files,
102 		space. If the text is part of a category, such as <tt>Authors</tt>, put
164 	\note This is only for the source files and for you as documenter. It will
171 	(\\) and are followed by whitespace (such as a space or a newline), with the
201 		Tells Doxygen that the following section is going to be on the class as
207 		scope operator, \c ::, are to be added as well. Modifiers such as \c
212 		have the classname and the scope operator as well.
232 	start of that section. All the commands take a paragraph as answer. A
298 	associated with any kind of module, such as files or classes, and therefore,
312 	same arguments as \c \\page, namely the \c \<name\> and the
319 		line so as to provide readability. It is not necessary to indent
320 		sections and subsections more than the normal two spaces, as long as you
326 		better off as a big tutorial on the Haiku website.
332 	it as an index.
338 	of operation they perform, such as appending, finding, etc. Defining groups
339 	is currently not as powerful as it could be, but if you use it inside
367 	block can be as long or short as you want, but please don't make it too
382 	paragraphs as a single contiguous entity, it's not possible to mark up the
399 	location as the dox file, so only the file name will suffice.
410 	\c \\link which refers to members. The first one is takes one word as an
450 	- The point is for a specific audience, such as beginners in the Haiku API.
492 	as inconvenient. At the moment, how to actually group the documentation is
519 	\remarks \\brief documentation for files is about what it \e implements, as
525 	Classes are the basic building blocks in the Haiku API and as such have
529 	to include every item, it merely serves as a guiding principle that helps
567 	writing the actual documentation. There are some guidelines as to how, but
579 		like "Starts the timer", but rather as what it will do: "Start the
586 		command for that. For the description, use a short phrase such as "The
615 	constants, as well as enumerations and their values. If you need to document
644 	for and what they might be used for, as well as which classes and functions
649 	Defines are usually used as message constants. Give a short description of
658 	individual members (which you should do for the named enumerations as well),
663 	it, where it might be used, etcetera. Don't go as far as to copy information
677 	will be printed as a title and will enhance the clarity of what the group
678 	contains. If you put the \c \\name command as the first command of a group,
679 	the rest of the words on that line will be used as the title. You should
684 	for what purpose. See it as a quick subdivision that a developer could use
685 	as a guide to see which method he actually wants to use. Don't go on
699 	comparison function, such as BList::SortItems().
700 	See the String.h documentation file to see the specifics, as they are
701 	basically the same as implemented in this class.