@@ -65,6 +65,11 @@ There is also **great**, **free** hosting for your Sphinx_ docs:
65
65
your source repository so that rebuilding your documentation will
66
66
happen automatically.
67
67
68
+ When run, Sphinx _ will import your code and using Python's introspection
69
+ features it will extract all function, method and class signatures. It will
70
+ also extract the accompanying docstrings, and compile it all into well
71
+ structured and easily readable documentation for your project.
72
+
68
73
.. note ::
69
74
70
75
Sphinx is famous for its API generation, but it also works well
@@ -127,6 +132,30 @@ Some tools use docstrings to embed more-than-documentation behavior,
127
132
such as unit test logic. Those can be nice, but you won't ever go
128
133
wrong with vanilla "here's what this does."
129
134
135
+ Tools like Sphinx _ will parse your docstrings as reStructuredText and render it
136
+ correctly as HTML. This makes it very easy to embed snippets of example code in
137
+ a project's documentation.
138
+
139
+ Additionally, Doctest _ will read all embedded docstrings that look like input
140
+ from the Python commandline (prefixed with ">>>") and run them, checking to see
141
+ if the output of the command matches the text on the following line. This
142
+ allows developers to embed real examples and usage of functions alongside
143
+ their source code, and as a side effect, it also ensures that their code is
144
+ tested and works.
145
+
146
+ ::
147
+
148
+ def my_function(a, b):
149
+ """
150
+ >>> my_function(2, 3)
151
+ 6
152
+ >>> my_function('a', 3)
153
+ 'aaa'
154
+ """
155
+ return a * b
156
+
157
+ .. _Doctest : https://docs.python.org/3/library/doctest.html
158
+
130
159
Docstrings versus Block comments
131
160
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
132
161
@@ -141,8 +170,82 @@ comment block is a programmer's note. The docstring describes the
141
170
""" Returns the square root of self times self."""
142
171
...
143
172
144
- .. see also:: Further reading on docstrings: :pep:`257`
145
-
173
+ Unlike block comments, docstrings are built into the Python language itself.
174
+ This means you can use all of Python's powerful introspection capabilities to
175
+ access docstrings at runtime, compared with comments which are optimised out.
176
+ Docstrings are accessible from both the `__doc__ ` dunder attribute for almost
177
+ every Python object, as well as with the built in `help() ` function.
178
+
179
+ While block comments are usually used to explain *what * a section of code is
180
+ doing, or the specifics of an algorithm, docstrings are more intended for
181
+ explaining to other users of your code (or you in 6 months time) *how * a
182
+ particular function can be used and the general purpose of a function, class,
183
+ or module.
184
+
185
+ Writing Docstrings
186
+ ~~~~~~~~~~~~~~~~~~
187
+
188
+ Depending on the complexity of the function, method, or class being written, a
189
+ one-line docstring may be perfectly appropriate. These are generally used for
190
+ really obvious cases, such as::
191
+
192
+ def add(a, b):
193
+ """Add two numbers and return the result."""
194
+ return a + b
195
+
196
+ The docstring should describe the function in a way that is easy to understand.
197
+ For simple cases like trivial functions and classes, simply embedding the
198
+ function's signature (i.e. `add(a, b) -> result `) in the docstring is
199
+ unnecessary. This is because with Python's `inspect ` module, it is already
200
+ quite easy to find this information if needed, and it is also readily available
201
+ by reading the source code.
202
+
203
+ In larger or more complex projects however, it is often a good idea to give
204
+ more information about a function, what it does, any exceptions it may raise,
205
+ what it returns, or relevant details about the parameters.
206
+
207
+ For more detailed documentation of code a popular style is the one used for the
208
+ Numpy project, often called `Numpy style `_ docstrings. While it can take up a
209
+ few more lines the previous example, it allows the developer to include a lot
210
+ more information about a method, function, or class. ::
211
+
212
+ def random_number_generator(arg1, arg2):
213
+ """
214
+ Summary line.
215
+
216
+ Extended description of function.
217
+
218
+ Parameters
219
+ ----------
220
+ arg1 : int
221
+ Description of arg1
222
+ arg2 : str
223
+ Description of arg2
224
+
225
+ Returns
226
+ -------
227
+ int
228
+ Description of return value
229
+
230
+ """
231
+ return 42
232
+
233
+ The `sphinx.ext.napoleon `_ plugin allows Sphinx to parse this style of
234
+ docstrings, making it easy to incorporate NumPy style docstrings into your
235
+ project.
236
+
237
+ At the end of the day, it doesn't really matter what style is used for writing
238
+ docstrings, their purpose is to serve as documentation for anyone who may need
239
+ to read or make changes to your code. As long as it is correct, understandable
240
+ and gets the relevant points across then it has done the job it was designed to
241
+ do.
242
+
243
+
244
+ For further reading on docstrings, feel free to consult :pep: `257 `
245
+
246
+ .. _thomas-cokelaer.info : http://thomas-cokelaer.info/tutorials/sphinx/docstring_python.html
247
+ .. _sphinx.ext.napoleon : https://sphinxcontrib-napoleon.readthedocs.io/
248
+ .. _`NumPy style` : http://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_numpy.html
146
249
147
250
Other Tools
148
251
-----------
0 commit comments