Getting all the sections in a more beginner's friendly, logical order
JonasT
10 years ago
31 | 31 | |
32 | 32 | ## Commenting Conventions |
33 | 33 | |
34 | LDoc follows the conventions established by Javadoc and later by LuaDoc. | |
34 | LDoc follows the conventions established by Javadoc and later by LuaDoc to document the | |
35 | modules, functions, types (=classes) and so forth of your API. | |
36 | ||
37 | ### Doc comments | |
35 | 38 | |
36 | 39 | Only 'doc comments' are parsed; these can be started with at least 3 hyphens, or by a empty |
37 | 40 | comment line with at least 3 hypens: |
54 | 57 | warning issued. The only exception is if the module starts with an explicit `module` |
55 | 58 | statement. |
56 | 59 | |
60 | ||
61 | ### Summary and tags of a doc comment | |
62 | ||
57 | 63 | All doc comments start with a summary sentence, that ends with a period or a question mark. |
58 | 64 | An optional description may follow. Normally the summary sentence will appear in the module |
59 | 65 | contents. |
60 | 66 | |
61 | 67 | After this descriptive text, there will typically be _tags_. These follow the convention |
62 | 68 | established by Javadoc and widely used in tools for other languages. |
69 | ||
70 | The first important tag to know is the module tag: | |
71 | ||
72 | ### The module tag, naming and describing your API module | |
73 | ||
74 | The first thing in your API module should be a name and a description. | |
75 | This is how a module is commonly done in Lua 5.2 with a @module tag at the top | |
76 | which introduces the name: | |
77 | ||
78 | --- a test module | |
79 | -- @module test | |
80 | ||
81 | local test = {} | |
82 | ||
83 | function test.my_module_function_1() | |
84 | ... | |
85 | end | |
86 | ||
87 | ... | |
88 | ||
89 | return test | |
90 | ||
91 | This sets up a module named 'test' with the description 'a test module'. | |
92 | ||
93 | ### Describing functions with tags: | |
94 | ||
95 | The next thing to describe are the functions your module has. | |
96 | This is a simple example of a documented function: | |
63 | 97 | |
64 | 98 | --- foo explodes text. |
65 | 99 | -- It is a specialized splitting operation on a string. |
69 | 103 | .... |
70 | 104 | end |
71 | 105 | |
72 | There are also 'tparam' and 'treturn' which let you [specify a type](#Tag_Modifiers): | |
73 | ||
74 | -- @tparam string text the string | |
106 | The tags basically add all the detail that cannot be derived from the source code | |
107 | automatically. | |
108 | ||
109 | ### Most common tags | |
110 | ||
111 | Common tags are the 'param' tag which takes a parameter name followed by a parameter | |
112 | description separated by a space, and the 'return' tag which is simply followed by | |
113 | a description for a return value: | |
114 | ||
115 | -- @param name_of_parameter the description of this parameter as verbose text | |
116 | -- @return the description of the return value | |
117 | ||
118 | If you want to [specify a type](#Tag_Modifiers) for a parameter or a return value, | |
119 | there are also 'tparam' and 'treturn': | |
120 | ||
121 | -- @tparam string text this parameter is named 'text' and has the fixed type 'string' | |
75 | 122 | -- @treturn {string,...} a table of substrings |
76 | 123 | |
77 | 124 | There may be multiple 'param' tags, which should document each formal parameter of the |
78 | 125 | function. For Lua, there can also be multiple 'return' tags |
79 | ||
80 | --- solvers for common equations. | |
81 | module("solvers", package.seeall) | |
82 | 126 | |
83 | 127 | --- solve a quadratic equation. |
84 | 128 | -- @param a first coeff |
98 | 142 | end |
99 | 143 | |
100 | 144 | ... |
101 | ||
102 | This is the common module style used in Lua 5.1, but it's increasingly common to see less | |
103 | 'magic' ways of creating modules in Lua. Since `module` is deprecated in Lua 5.2, any | |
104 | future-proof documentation tool needs to handle these styles gracefully: | |
105 | ||
106 | --- a test module | |
107 | -- @module test | |
108 | ||
109 | local test = {} | |
110 | ||
111 | --- first test. | |
112 | function test.one() | |
113 | ... | |
114 | end | |
115 | ||
116 | ... | |
117 | ||
118 | return test | |
119 | ||
120 | Here the name of the module is explicitly given using the 'module' tag. If you leave this | |
121 | out, then LDoc will infer the name of the module from the name of the file and its relative | |
122 | location in the filesystem; this logic is also used for the `module(...)` idiom. (How this | |
123 | works and when you need to provide extra information is discussed later.) | |
145 | Of course there is also the 'module' tag which you have already seen. | |
146 | ||
147 | As an alternative to using the 'module' tag as described before, you | |
148 | can still start your modules the Lua 5.1 way: | |
149 | ||
150 | --- solvers for common equations. | |
151 | module("solvers", package.seeall) | |
152 | ||
153 | However, the 'module' function is deprecated in Lua 5.2 and it is increasingly | |
154 | common to see less 'magic' ways of creating modules, as seen in the description | |
155 | of the 'module' tag previously with the explicitely returned module table. | |
156 | ||
157 | ### Local module name | |
124 | 158 | |
125 | 159 | It is common to use a local name for a module when declaring its contents. In this case the |
126 | 160 | 'alias' tag can tell LDoc that these functions do belong to the module: |
148 | 182 | --- second test. |
149 | 183 | M.two = function(...) ... end |
150 | 184 | |
185 | ### Local functions | |
186 | ||
151 | 187 | Apart from exported functions, a module usually contains local functions. By default, LDoc |
152 | 188 | does not include these in the documentation, but they can be enabled using the `--all` flag. |
153 | 189 | They can be documented just like 'public' functions: |
160 | 196 | --- we need to give a hint here for foo |
161 | 197 | -- @local here |
162 | 198 | function foo(...) .. end |
199 | ||
200 | ### Tables and other constant values | |
163 | 201 | |
164 | 202 | Modules can of course export tables and other values. The classic way to document a table |
165 | 203 | looks like this: |
204 | 242 | occur once in a comment. The basic rule is that a single doc comment can only document one |
205 | 243 | entity. |
206 | 244 | |
245 | ### Alternative way of specifying tags | |
246 | ||
207 | 247 | Since 1.3, LDoc allows the use of _colons_ instead of @. |
208 | 248 | |
209 | 249 | --- a simple function. |
218 | 258 | In this style, types may be used directly if prefixed with '!' or '?' (for type-or-nil) |
219 | 259 | |
220 | 260 | (see @{colon.lua}, rendered [here](http://stevedonovan.github.io/ldoc/examples/colon)) |
261 | ||
262 | ### Which files are processed | |
221 | 263 | |
222 | 264 | By default, LDoc will process any file ending in '.lua' or '.luadoc' in a specified |
223 | 265 | directory; you may point it to a single file as well. A 'project' usually consists of many |