Remove Coding guidelines (moved to github wiki).

CODESTYLE.md

@@ -1,96 +0,0 @@
-Coding Guidelines
-=================
-
-Generally
----------
-
-Use use regular coding style:
-http://www.python.org/dev/peps/pep-0008/
-http://google-styleguide.googlecode.com/
-
-One can break those rules if the situation requires it. Keep it contained.
-
-
-Some specific rules for this package :
-
-Git
----
-
-This project use git-flow {nvie.com/posts/a-successful-git-branching-model}
-as a model for branches management. In particular :
-
- 1. master is for release only
- 2. when you commit to develop, run nosetests before. All tests should pass.
- 3. when you commit to develop, run nosetests before. All tests should pass.
- 4. when you commit to develop, run nosetests before. All tests should pass.
- 5. in 'feat/' branches, you do whatever you want.
- 6. when developping a new feature, write tests for it.
-
-
-Alignement
-----------
-
-We strive for code clarity first, and then conformance to pep-8.
-As such, any code alignement that make the code clearer, easier to use,
-edit and debug takes precedence over proper spacing.
-
-
-Strings
--------
-
-For literals strings, ' is preferred to ", but use " when the string contains '.
-
-- yes: "run the command 'flake8' before committing"
-- no : 'run the command \'flake8\' before committing'
-
-
-Use '.format' syntax for strings, and '+' only when the use calls it.
-Don't mix and match.
-
-- yes: s = color + s + end
-- yes: '{}: file {} could not be read'.format(errorname, filepath)
-- no : errorname + ': file {} could not be read'.format(filepath)
-
-
-Names
------
-
-Avoid at all cost to name a variable like a module from the package, a
-dependency or the standart lib.
-This breaks coherence across the code, makes it harder to read.
-Change either the module or variable name.
-
-
-Function that have only local uses should be preceded by an underscore.
-
-- yes:
-
-        def _auxiliary_local_fun():
-            pass
-
-- no:
-
-        def auxiliary_local_fun():
-            pass
-
-These functiona won't be imported automatically with the module.
-It keeps the interface clean, makes occasional hacks explicit, and inform other
-developers that theses functions may need special care when uses outside their
-natural habitat.
-
-
-Files
------
-
-Unless you have a good reason, use 'open' as such :
-
-- yes:
-
-        with open(path, 'w') as f:
-             f.read()
-
-- no:
-
-        f = open(path, 'r')
-                f.read()
-        f.close()