Add Hacking and Authors to bring this into accordance with OpenStack coding standards
This commit is contained in:
parent
7e5a474d0d
commit
8f19567ecd
16
AUTHORS
Normal file
16
AUTHORS
Normal file
@ -0,0 +1,16 @@
|
||||
Andrey Brindeyev <abrindeyev@griddynamics.com>
|
||||
Brian Lamar <brian.lamar@rackspace.com>
|
||||
Brian Waldon <brian.waldon@rackspace.com>
|
||||
Chris Behrens <cbehrens@codestud.com>
|
||||
Christopher MacGown <chris@pistoncloud.com>
|
||||
Ed Leafe <ed@leafe.com>
|
||||
Eldar Nugaev <eldr@ya.ru>
|
||||
Ilya Alekseyev <ilyaalekseyev@acm.org>
|
||||
Johannes Erdfelt <johannes.erdfelt@rackspace.com>
|
||||
Josh Kearney <josh@jk0.org>
|
||||
Kevin L. Mitchell <kevin.mitchell@rackspace.com>
|
||||
Kirill Shileev <kshileev@griddynamics.com>
|
||||
Lvov Maxim <mlvov@mirantis.com>
|
||||
Matt Dietz <matt.dietz@rackspace.com>
|
||||
Sandy Walsh <sandy.walsh@rackspace.com>
|
||||
jerdfelt <johannes@erdfelt.com>
|
75
HACKING
Normal file
75
HACKING
Normal file
@ -0,0 +1,75 @@
|
||||
Nova Style Commandments
|
||||
=======================
|
||||
|
||||
Step 1: Read http://www.python.org/dev/peps/pep-0008/
|
||||
Step 2: Read http://www.python.org/dev/peps/pep-0008/ again
|
||||
Step 3: Read on
|
||||
|
||||
Imports
|
||||
-------
|
||||
- thou shalt not import objects, only modules
|
||||
- thou shalt not import more than one module per line
|
||||
- thou shalt not make relative imports
|
||||
- thou shalt organize your imports according to the following template
|
||||
|
||||
::
|
||||
# vim: tabstop=4 shiftwidth=4 softtabstop=4
|
||||
{{stdlib imports in human alphabetical order}}
|
||||
\n
|
||||
{{nova imports in human alphabetical order}}
|
||||
\n
|
||||
\n
|
||||
{{begin your code}}
|
||||
|
||||
|
||||
General
|
||||
-------
|
||||
- thou shalt put two newlines twixt toplevel code (funcs, classes, etc)
|
||||
- thou shalt put one newline twixt methods in classes and anywhere else
|
||||
- thou shalt not write "except:", use "except Exception:" at the very least
|
||||
- thou shalt include your name with TODOs as in "TODO(termie)"
|
||||
- thou shalt not name anything the same name as a builtin or reserved word
|
||||
- thou shalt not violate causality in our time cone, or else
|
||||
|
||||
|
||||
Human Alphabetical Order Examples
|
||||
---------------------------------
|
||||
::
|
||||
import httplib
|
||||
import logging
|
||||
import random
|
||||
import StringIO
|
||||
import time
|
||||
import unittest
|
||||
|
||||
from nova import flags
|
||||
from nova import test
|
||||
from nova.auth import users
|
||||
from nova.endpoint import api
|
||||
from nova.endpoint import cloud
|
||||
|
||||
Docstrings
|
||||
----------
|
||||
"""A one line docstring looks like this and ends in a period."""
|
||||
|
||||
|
||||
"""A multiline docstring has a one-line summary, less than 80 characters.
|
||||
|
||||
Then a new paragraph after a newline that explains in more detail any
|
||||
general information about the function, class or method. Example usages
|
||||
are also great to have here if it is a complex class for function. After
|
||||
you have finished your descriptions add an extra newline and close the
|
||||
quotations.
|
||||
|
||||
When writing the docstring for a class, an extra line should be placed
|
||||
after the closing quotations. For more in-depth explanations for these
|
||||
decisions see http://www.python.org/dev/peps/pep-0257/
|
||||
|
||||
If you are going to describe parameters and return values, use Sphinx, the
|
||||
appropriate syntax is as follows.
|
||||
|
||||
:param foo: the foo parameter
|
||||
:param bar: the bar parameter
|
||||
:returns: description of the return value
|
||||
|
||||
"""
|
Loading…
Reference in New Issue
Block a user