Code Specs and Developer Workflow

Because the Moving Target Pipeline is a large multideveloper project with both data and code deliverable a consistent approach to programming style and procedures is important. When in doubt we use the astropy project as a guide: http://www.astropy.org/index.html

Coding Style

The project coding style is generally defined by the Python Enhancement Proposal 8 (PEP8): http://legacy.python.org/dev/peps/pep-0008/. Further clarification and specification can be found in the Google Python Style Guide: http://google-styleguide.googlecode.com/svn/trunk/pyguide.html. In the case of a conflict or uncertainty consult @acviana. In both cases these are only conventions and can be broken anywhere it's justified - provided it's justified.

PEP 8 compliance can be automatically assessed using the pylint linter, either through the command line tool with the Sublime Text plugin (I'm sure similar plugins exist for other editors as well). Note that pylint is more stringent with the PEP 8 conventions that we need to be, a score of 8/10 is usually sufficient.

Docstrings

A multiline docstring is required for every module, function, and class in the codebase. Simple methods may have a one-line docstring but more complicated methods should also use a multiline docstring format. Docstring should be in encased in double-quotes """like this""". Comments (#) should be used sparingly in favor of docstrings and clear variable names. Per PEP8 they should only be 72 characters wide.

The docstrings should be written in reStructuredSext markup and will be converted to HTML using sphinx. The required sections for each type of docstring are described here [XXX].

Docstring should be written with the assumption that the reader can understand the Python it's describing. Thus, docstrings should primarily explain what the code is doing, e.g. _"applying a median correction" and not how the code is doing it "e.g. looping over the columns". To this end extra attention should be paid to the readability of the code itself.

Not all legacy code in the project will follow this convention but dostrings should be updated to the correct format anytime the corresponding code is updated.

Repository Organization

We are in the process of reorganizing the repository into the following structure:

.
|-- .gitignore
|-- docs/
|-- mtpipeline/
|  |-- __init__.py
|  |-- imaging/
|  |  |-- __init__.py
|  |  |-- foo.py
|  |-- database/
|  |  |-- __init__.py
|  |  |-- foo.py
|  |-- ephem/
|  |  |-- __init__.py
|  |  |-- foo.py
|  |-- tests/
|  |  |-- __init__.py
|  |  |-- imaging/
|  |  |  |-- test_foo.py
|  |  |-- database/
|  |  |  |-- test_foo.py
|  |  |-- ephem/
|  |  |  |-- test_foo.py
|-- setup.py
|-- scripts/
|  |-- run_foo.py

A couple of notes, the docs folder will contain the HTML output from sphinx. The tests module will contain a duplicate of the package tree structure (excluding the tree module itself) which the test for each module foo/bar.py in a module called tests/foo/test_bar.py. All tests will be unit tests run by the nosetests package. End-to-end testing will be performed by hand in development environments. Data completeness will be validated by other scripts.

The code in the main mtpipeline package should library quality code. In particular this means a couple of things. No user names, absolute paths, server names, or passwords should be anywhere in the codebase. These values should instead be stored in a file at the top of the repository called settings.yaml, this file is excluded by the .gitignore settings. * The main package also shouldn't contain any command line argument parsing, logging, or monitoring code (email on crash or complete). These should instead be included in the thin wrappers found in the scripts folder.

• In general, you should never store passwords as plain text. However, because we are only accessing localhost MySQL instances in our development environment this isn't an issue. When we are ready to move the system into production we can ask ITSD how the would like us to implement and required security features.