Module:Sandbox/Jeblad/LuaDoc/doc explained
Usage
Usual call for documentation of a single module, like a replacement for the usual documentation page, would be like this
In the actual code there will be specially formatted comments. All comments acted upon by this use a single line comment followed by an at sign (@) and a tag name. (Is there any reason why we should use other kinds of comments? They are useful for commenting out blocks? How to describe local functions? Should inline docs be used, those can be supported by wikitext?)
Note that all text is processed as wikitext, and it is possible to link internally and externally as seems fit. This also creates some problems as part of the text will have spaces or page breaks in odd places.
A summary-line is prefixed by three (3) hyphens (dashes), and double as a marker for the place where the code is to be divided into chunks. The stuff in each chunk is processed separately. The summary will be marked as such, and it will be possible to use it as a fragment identifier.
A tag is prefixed by two (2) hyphens (dashes), optional spaces, a single at-sign (@) and a tag name. The following text can be further split and given special markup.
A single line comment following a summary or tag will be joined with the preceding line. If the line contains text it will be joined with a dividing space, if it is empty it will add a newline. The newline can be further processed and given special markup.
Recognized tags can be removed from the document flow or left in place, as seems fit for the processed chunk of text. Those removed from the document can be added to separate lists for separate processing or rejected altogether.
Unrecognized tags will be rendered in place with a generic mechanism.
All tags with a leading x- will be rejected, no matter if they can be recognized or not.
Available tags
A series of different tags are recognized. They capture words or other constructs, and will process the captures specially. The captures will be formatted and linked as necessary. The remaining text is treated as ordinary wikitext.
If a tag taking captures fails to detect a capture, then possible captures will be successively pushed out, ultimately pushing all possible captures into the following text. This can be used in some cases to avoid using a specific capture, but is an indication that the documentation is broken.
It is the intention to support the listed tags, but others can be added later. The block tags from JSdoc could be a source for additional entries.[1]
- @author* : Identify the author of an item. Authors are those that have contributed with content to the item.
@copyright* : Document some copyright information. Copyright is an identification of the entity that is allowed to set the license.
@license* : Identify the license that applies to this code. The license is the document that says why a module can be reused.
@provenance* : Document the history of ownership for the module. Link this to the external source if suitable.
@release? (alt @version) : Identify the release or version number of an item. This is necessary for imported modules.
@since? [''date''|''version''|''revision''] : Document when this feature was added. The date, version, or revision when some functionality was added.
@deprecated? [''date''|''version''|''revision''] : Document when this feature was deprecated. The date, version, or revision is when some functionality become deprecated.
@var? [''word''|''descriptor''] : Describe a variable definition. First field is a type declaration. This implies a variable-class. (Not sure about this one, its like the signature of the function.)
@field* [''word''|''descriptor''] : Describe a table field definition. First field is a type declaration. This implies a variable-class.
@param* [''word''|''descriptor''] (alt @arg, @argument) : Document the parameter to a function. First field is a type declaration. This implies a function-class.
@returns* (alt @return) : Document the return values of a function. Since Lua can return multiple values, this tag could appear more than once. This implies a function-class.
@see* : Refer to some other documentation for more information. This tag spawns an entry possibly with links in a navigation box.
@usage <text> : Describe the usage of the function or variable. This is one of several such free sections. The tag will be localized as necessary. (Not sure about this one, perhaps name the individual modifiers.)
- * Zero or more entries
- + One or more entries
- ? Zero or one entry
Inferred tags
Some tags will be extracted from the following block of code if missing (it is the intention to support these)
- @class <word> : The first documentation block will be assumed to be of class module, and later ones will have classes inferred from the code block unless it is specified explicitly.
@description <text> : The description is the documentation following the summary, but can be set explicitly. (Not sure if this should be described here, and if it should have a tag.)
@name <word> : The name of the function or table definition. This is usually inferred from simple code analysis, and the programmer does not need to define it. (The programmer should not add it at all.)
@access <word> : Whether the function or variable is public or private. This will be error prone if inferred from the code.
@signature <line> : A signature inferred from a single line of code.
Additional comments
There are available block comments in Lua, and they can also be used in code documented with LuaDoc. The commented blocks will be removed before further processing, making the resulting documentation stripped down to the bare running code.
In Lua a block comment starts like -- and run until the corresponding . Actually, if we add an additional leading hyphen then the comment will be turned into a single line comment. That leads to a situation whereby the following code can comment out a piece of code --print(10) -- no action (comment) --Now, if we add a single hyphen to the first line, the code is in again: ---print(10) --> 10 --
To formalize this a little we will say that LuaDoc only act upon comments that are on a line by themselves. Other block comments are simply left as they are.
Block comments can be specified a bit more, leading to nested comments. The regex we are using for block comments is like \n%s*\-\-%b[](=*)&[].*\]\1\]
External links
Notes and References
- Web site: Block Tags. @use JSDoc.
