Add coding guidelines

These are the coding guidelines as updated from what originally was in
PyCogent. I took a pass through the document and updated where I saw fit,
however I know that people will like to add things that are currently not being
covered, so let me know and I'll add/change as needed.

The section that needs the most attention is the testing section. I updated it
but I know there might still be things that are missing as I'm not super
familiar with nose.

I've also added a minimal section about git that mainly points to other well
known and well written git guides.

Fixes #272
Gotcha, thanks!

On (Jun-11-14|10:22), Jorge Cañardo Alastuey wrote:
> > +There are several different approaches for testing code in python: ``nose``, ``unittest`` and ``numpy.testing``. Their purpose is the same, to check that execution of code given some input produces a specified output. The cases to which the approaches lend themselves are different.
> > +
> > +Whatever approach is employed, the general principle is every line of code should be tested. It is critical that your code be fully tested before you draw conclusions from results it produces. For scientific work, bugs don't just mean unhappy users who you'll never actually meet: **they may mean retracted publications**.
> > +
> > +Tests are an opportunity to invent the interface(s) you want. Write the test for a method before you write the method: often, this helps you figure out what you would want to call it and what parameters it should take. It's OK to write the tests a few methods at a time, and to change them as your ideas about the interface change. However, you shouldn't change them once you've told other people what the interface is.
> > +
> > +Never treat prototypes as production code. It's fine to write prototype code without tests to try things out, but when you've figured out the algorithm and interfaces you must rewrite it *with tests* to consider it finished. Often, this helps you decide what interfaces and functionality you actually need and what you can get rid of.
> > +
> > +"Code a little test a little". For production code, write a couple of tests, then a couple of methods, then a couple more tests, then a couple more methods, then maybe change some of the names or generalize some of the functionality. If you have a huge amount of code where all you have to do is write the tests', you're probably closer to 30% done than 90%. Testing vastly reduces the time spent debugging, since whatever went wrong has to be in the code you wrote since the last test suite. And remember to use python's interactive interpreter for quick checks of syntax and ideas.
> > +
> > +Run the test suite when you change `anything`. Even if a change seems trivial, it will only take a couple of seconds to run the tests and then you'll be sure. This can eliminate long and frustrating debugging sessions where the change turned out to have been made long ago, but didn't seem significant at the time.
> > +
> > +Some pointers
> > +^^^^^^^^^^^^^
> > +
> > +- *Use the* ``unittest`` *or the* ``nose`` *framework with tests in a separate file for each module.* Name the test file ``test_module_name.py`` and include it inside the tests forlder for the module. Keeping the tests separate from the code reduces the temptation to change the tests when the code doesn't work, and makes it easy to verify that a completely new implementation presents the same interface (behaves the same) as the old.
> 
> As long as all tests are run and found by `nostests`, `python foo/test_bar.py` and `foo.bar.test()` it doesn't matter if you use plain unittest or also depend on nose.
> Note that there's a lot of overlap between unittest, nose and numpy.testing (nose extends unittest, nose.tools wraps unittest methods with more_pythonic_names and adds more assertion functions, and numpy also adds array-specific stuff).
> See #269 for more information!
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/biocore/scikit-bio/pull/401/files#r13661778