@@ -65,6 +65,11 @@ There is also **great**, **free** hosting for your Sphinx_ docs:
6565your source repository so that rebuilding your documentation will
6666happen automatically.
6767
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+
6873.. note ::
6974
7075 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,
127132such as unit test logic. Those can be nice, but you won't ever go
128133wrong with vanilla "here's what this does."
129134
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+
130159Docstrings versus Block comments
131160~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
132161
@@ -141,8 +170,82 @@ comment block is a programmer's note. The docstring describes the
141170 """ Returns the square root of self times self."""
142171 ...
143172
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
146249
147250Other Tools
148251-----------
0 commit comments