Oregon State University
2025-02-05
Professor Carole Goble in “Better Software, Better Research”:
One of my favorite #overlyhonestmethods tweets (a hashtag for lab scientists) is Ian Holmes’s “You can download our code from the URL supplied. Good luck downloading the only postdoc who can get it to run, though.”
README
: sits in top-level directory and contains all the necessary information for installing, getting started with, and understanding the accompanying code.
May be accompanied by other specific files: LICENSE
, INSTALL
, CITATION
, ABOUT
, CHANGELOG
, CONTRIBUTING
SQUIRREL, version 1.2 released on 2026-09-20
# About
The Spectral Q and U Imaging Radiation Replicating Experimental Library
(SQUIRREL) is a library for replicating radiation sources with spectral details
and Q and U polarizations of superman bubblegum.
# Installation
The SQUIRREL library relies on other libraries:
- The ACORN library www.acorn.nutz
- The TREEBRANCH database format API
Install those before installing the SQUIRREL library. To install the SQUIRREL
library:
./configure
make --prefix=/install/path
make install
...
Also possible to pollute code with unnecessary cruft:
def decay(index, database):
# first, retrieve the decay constants from the database
mylist = database.decay_constants()
# next, try to access an element of the list
try:
d = mylist[index] # gets decay constant at index in the list
# if the index doesn't exist
except IndexError:
# throw an informative error message
raise Exception("value not found in the list")
return d
Code written cleanly will have its own voice. Use intelligent naming to make most lines of code clear without comments, then use comments sparingly to help explain reasons or complicated sections:
Naming: a class, variable, or function name should tell you why it exists, what it does, and how it is used.
Simple functions: functions should be small to be understandable and testable; they should only do one thing.
Consistent style: use a consistent, standardized style; e.g., select variable and function names according to the PEP8 style guide for Python.
# packages and modules are short and lowercase
packages
modules
# other objects can be long
ClassesUseCamelCase
ExceptionsAreClassesToo
functions_use_snake_case
CONSTANTS_USE_ALL_CAPS
# variable scope is *suggested* by style convention
_single_leading_underscore_ # internal to module
single_trailing_underscore_ # avoids conflicts with Python keywords
__double_leading_trailing__ # these are magic, like __init__
docstring: comment placed immediately after a function or class definition, typically enclosed by three pairs of double quotes:
docstrings are available within Python via help()
and iPython’s magic command ?
, and Sphinx picks them up.
Make docstrings descriptive and concise; you can explain the arguments of a function, its behavior, and how you intend it to be used.
Sphinx can be used to automate the generation of HTML documentation; we can even use it with GitHub Actions to automatically build and deploy the docs on GitHub Pages.
For now, let’s just make sure your docstrings are suitable for Sphinx.
def function_with_types_in_docstring(param1, param2):
"""Example function with types documented in the docstring.
`PEP 484`_ type annotations are supported. If attribute, parameter, and
return types are annotated according to `PEP 484`_, they do not need to be
included in the docstring:
Parameters
----------
param1 : int
The first parameter.
param2 : str
The second parameter.
Returns
-------
bool
True if successful, False otherwise.
.. _PEP 484:
https://www.python.org/dev/peps/pep-0484/
"""
def function_with_types_in_docstring(param1, param2):
"""Example function with types documented in the docstring.
`PEP 484`_ type annotations are supported. If attribute, parameter, and
return types are annotated according to `PEP 484`_, they do not need to be
included in the docstring:
Args:
param1 (int): The first parameter.
param2 (str): The second parameter.
Returns:
bool: The return value. True for success, False otherwise.
.. _PEP 484:
https://www.python.org/dev/peps/pep-0484/
"""
pip install sphinx myst-parser
mkdir docs
cd docs
sphinx-quickstart
(accept defaults if unsure; answer “yes” for question about autodoc)source
directory holds .rst
and .md
files for user guides, theory manuals, etc., separate from the autogenerated API documentationdocs\source
directory, add an installation.md
file (for example)'myst_parser'
to extensions
in conf.py
make html
.md
files for each module.conf.py
)'sphinx.ext.autodoc'
to extensions
sphinx.ext.napoleon
(for Google/NumPy-style docstring reading) and sphinx.ext.mathjax
(if you want LaTeX-based equations), and sphinx.ext.intersphinx
for connections to other docsnapoleon_numpy_docstring
and napoleon_google_docstring
to True
/False
depending on your docstring style.intersphinx_mapping
dict to connect to other docsconf.py
, add autodoc_default_options = {'members': True}
and autoclass_content = 'class'
[modulename].rst
file in the docs\source
directory. Add .. automodule:: [packagename].[modulename]
index.rst
, add [modulename]
inside the toctree
(table of contents)intersphinx_mapping
name: "Sphinx: Render docs"
on: push
jobs:
build:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v4
with:
persist-credentials: false
- name: install depedendices
run : |
python -m pip install --upgrade pip
pip install .
pip install sphinx myst-parser
- name: Build HTML
run: |
cd docs
make html
- name: Upload artifacts
uses: actions/upload-artifact@v4
with:
name: html-docs
path: docs/build/html/
- name: Deploy
uses: peaceiris/actions-gh-pages@v4
if: github.ref == 'refs/heads/main'
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
publish_dir: docs/build/html
sphinx.ext.githubpages
to extensions
in conf.py
docs/requirements.txt
file for any dependencies (e.g., myst-parser
)gh-pages
branch in the “Source” dropdownMore on Sphinx - GitHub Actions here: https://www.sphinx-doc.org/en/master/tutorial/deploying.html
Comments
Comments provide a way to insert metainformation about code intended for people, right next to the code: