Clean up development guide

doc/source/development.rst

@@ -5,9 +5,11 @@ Development Guide
 =================
 
 
-All contributions to **parsnip** are welcome!
-Developers are invited to contribute to the framework by pull request to the package repository on `GitHub`_, and all users are welcome to provide contributions in the form of **user feedback** and **bug reports**.
-We recommend discussing new features in form of a proposal on the issue tracker for the appropriate project prior to development.
+All contributions to **parsnip** are welcome! Developers are invited to contribute to
+the framework by pull request to the package repository on `GitHub`_, and all users are
+welcome to provide contributions in the form of **user feedback** and **bug reports**.
+We recommend discussing new features in form of a proposal on the issue tracker for the
+appropriate project prior to development.
 
 .. _github: https://github.com/glotzerlab/parsnip
 
@@ -16,10 +18,12 @@ General Guidelines
 
 All code contributed to **parsnip** must adhere to the following guidelines:
 
-* Hard dependencies (those that end users must install to use **parsnip**) are *strongly* discouraged, and should be avoided where possible. Additional dependencies required by developers (those used to run tests or build docs) are allowed where necessary.
+* Hard dependencies (those that end users must install to use **parsnip**) are *strongly* discouraged, and should be avoided where possible. Additional dependencies required by developers (those used to run tests or build docs) are allowed if necessary.
 * All code should adhere to the source code conventions and satisfy the documentation and testing requirements discussed below.
 
-As portability is a primary feature of **parsnip**, tests are run run on Python versions 3.7 and later. However, first class support should only be expected for versions covered by `NEP 29`_.
+As portability is a primary feature of **parsnip**, tests are run run on Python versions
+3.9 and later. However, first class support should only be expected for versions covered
+by `NEP 29`_.
 
 .. _NEP 29: https://numpy.org/neps/nep-0029-deprecation_policy.html
 
@@ -43,9 +47,10 @@ API documentation should be written as part of the docstrings of the package in
 Docstrings are automatically validated using `pydocstyle <http://www.pydocstyle.org/>`_ whenever the ruff prek hooks are run.
 The `official documentation <https://parsnip.readthedocs.io/>`_ is generated from the docstrings using `Sphinx <http://www.sphinx-doc.org/en/stable/index.html>`_.
 
-In addition to API documentation, inline comments are strongly encouraged.
-Code should be written as transparently as possible, so the primary goal of documentation should be explaining the algorithms or mathematical concepts underlying the code.
-Multiline comments for regex strings may sometimes be necessary.
+In addition to API documentation, inline comments are strongly encouraged. Code should
+be written as transparently as possible, so the primary goal of documentation should
+be explaining the algorithms or mathematical concepts underlying the code.
+
 
 Building Documentation
 ^^^^^^^^^^^^^^^^^^^^^^
@@ -65,4 +70,7 @@ All code should include a set of tests which validate correct behavior.
 All tests should be placed in the ``tests`` folder at the root of the project.
 In general, most parts of parsnip primarily require `unit tests <https://en.wikipedia.org/wiki/Unit_testing>`_, but where appropriate `integration tests <https://en.wikipedia.org/wiki/Integration_testing>`_ are also welcome. Core functions should be tested against the sample CIF files included in ``tests/sample_data``.
 Tests in **parsnip** use the `pytest <https://docs.pytest.org/>`__ testing framework.
+Doctests are automatically integrated with ``pytest`` via
+`pytest-doctestplus <https://github.com/scientific-python/pytest-doctestplus>`_.
+
 To run the tests, simply execute ``pytest`` at the root of the repository.