From 66ae19c256da8fd8166fd16bab266d48bf687c74 Mon Sep 17 00:00:00 2001 From: Olivier Mangin Date: Wed, 16 Apr 2014 15:50:13 +0200 Subject: [PATCH] Remove Coding guidelines (moved to github wiki). --- CODESTYLE.md | 96 ---------------------------------------------------- 1 file changed, 96 deletions(-) delete mode 100644 CODESTYLE.md diff --git a/CODESTYLE.md b/CODESTYLE.md deleted file mode 100644 index d7d47e0..0000000 --- a/CODESTYLE.md +++ /dev/null @@ -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()