Code documentation

Clojure functions are documented by adding a string to the function definition. This is refered to as the doc string.

  1. (defn example-function
  2.   "This is the documentation for this function, refered to as a doc string"
  3.   [arguments]
  4.   (str "some behaviour"))

def bindings can also be documented to provide context to the data the name is bound to.

  1. (def weather-data
  2.   "Data set for weather across the major capitals of Europe"
  3.   [{:date "2020-05-015" :city "Berlin" :temperature-max 24 :temperature-min 13 :rainfall 1}
  4.    {:date "2020-05-015" :city "Amsterdam" :temperature-max 25 :temperature-min 14 :rainfall 0}])

Write easily understandable docstrings

Practically recommends including specific details of the arguments passed to a function and the expected return type. Including this at the end of the docstring makes that information very quick to find.

  1.   "Geographic visualization data set generator
  3.   Arguments:
  4.   - combined data set of GeoJSON and Cases
  5.   - maximum integer value for scale
  6.   Returns:
  7.   - Oz view hash-map"

Reading source code

clojure.repl/source will show the source code of a given function, which can be a valuable way to understand the function. Reading function source code also provides ideas when writing custom Clojure code.

Reading the source code for clojure.core functions is a good way to learn those functions, although some functions have been optomised for performance and are harder to follow.

Source code for clojure.core is available online and is also linked to from the function descriptions on clojuredocs.org.

Writing your own documentation

Writing good documentation for your own functions take practice which pays off in the long run.

Note::Define your own function

Practice writing a meaningful documentation in the doc string

  1. ()
  1. (defn my-function
  2.   "I should practice writing clear and meaningful documentation for my functions.
  3.   Arguments: brief description of arguments"
  4.   [arguments]
  5.   (str "I should write pure functions where ever possible. "
  6.        "Each function should have a specific purpose. "
  7.        "A function should be clean and easy to read."))