HORNET / docs / develop.rst

Full commit

HORNET Developers Guide

HORNET is a written in Python, a modern, high-level programming language. Currently, it is targeted for Python 2.5/2.6. It is available under the :doc:`Apache License, Version 2 </license>`.

Source Repository

The development branch is located at . You can check the code out with Mercurial:

$ hg clone hornet

For more information, check out the quick start guide.

Eclipse IDE

The development environment of choice is currently Eclipse with the PyDev plugin. Optionally, you can use the MercurialEclipse plugin to use Mercurial from within Eclipse.

Style Guidelines

Project Layout

Code Style

In general, we follow the coding style set forth in PEP 8.

David Goodger, Michael Foord, and Leonardo Maffi have useful additional helpful points about Python style.

Unit Testing

Ensuring code quality and accuracy of computations is paramount for HORNET. To this end, we strive to obtain a very high degree of test coverage of our code. The main method of testing is simple unit tests, which test the code at a low level (typically at the method or function level).

Tests are located at :file:`{HORNET_HOME}/tests`. In general each test module represents the corresponding module in :file:`{HORNET_HOME}/src`.

Tests general are written in the nose style. For example, if we have a function square():

def square(x):
    return x * x

We can write a simple test for this function:

def test_square():
    assert square(4) == 16

To run the entire HORNET test suite, there is a paver task:

$ paver test


Since HORNET is a framework, it is important that 3rd party developers be able to view complete, up-to-date documentation of how HORNET works and how they can extend it.

We use Sphinx for handwritten and API documentation. It uses reStructured Text as its markup format. The documentation source files are located at :file:`{HORNET_HOME}/docs`. Sphinx can also pull in the docstrings from any Python source file, thus aiding in API documentation.

$ paver htmlserve

Often, it is useful to include simple examples of how code should work in the documentation (referred to as doctests. To ensure that the examples in the documentation actually work, we use a paver task to test the examples:

$ paver doctest

Continuous Integration Server

In order to ensure that the code in the public repository is constantly is a healthly state, we use a continuous integration server to detect any code changes (i.e. pushes to the repository), build to code, and run the test suite. The goal is to only push code to the repository when it is in a buildable state. We currently use Hudson at:

Issue Tracking

We host a bug tracking system at Google Code. Please submit issues to to this issue tracker.