[Bro-Dev] first try at a skeleton script
robin at icir.org
Wed Sep 29 15:27:05 PDT 2010
Regarding the TODO: "Figure out a style for Sphinx-type
documentation", here are my thoughts:
- As a general rule, I guess a comment block should always be
associated with the next language element.
- The script itslef should start with a block describing the
overall purpose of the script and perhaps potential
caveats/things to keep in mind etc.
- Each indidivual doc section should start with a single short
sentence summarizing the documented element, followed by further
text going into more detail.
- Generally, all doc text is formatted in reST. However, one
thing I always hate when writing documentation strings is adding
all kinds of markers for things like parameters, return values,
etc. (e.g., "@param", or ":param:"). What I've played with for
HILTI is reducing this stuff to a minimum and extracting it from
the structure of the text. Example:
# Function for checking That.
# This function checks That and also does This, and
# sometimes even More.
# id: The connection for doing That.
# Returns: True if That was successful.
global check_that: function(id: conn_id): bool;
We can parse everything out here that we need:
- anything that's of the form "x: texttextext" is a parameter
(with type information inferred from the prototype, not typed
- "Returns: texttextext" is the magic to mark the description
of the return value.
This can be implemented via a pretty simple Sphinx plugin.
Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org
More information about the bro-dev