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
I don't think such discussion exists in CONTRIBUTING.md already, I'm
adding a parragraph about it.

On (Jun-10-14|11:52), Greg Caporaso wrote:
> > +.. _`Jim Fulton`: http://www.python.org/pycon/dc2004/papers/4/PyCon2004DocTestUnit.pdf
> > +
> > +How should I test my code ?
> > +---------------------------
> > +
> > +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.
> 
> Should we point to the discussion in ``CONTRIBUTING.md`` here about what tests are run by travis and how to run those locally? It's really frustrating to have tests pass locally and then fail when travis runs them because you were testing differently. 
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/biocore/scikit-bio/pull/401/files#r13611868