Files
7a1b622ed6088aaaa711b44c50a26e1a33695f63
nova /HACKING

133 lines
3.9 KiB
Plaintext
Raw Normal View History

2010年05月27日 23:05:26 -07:00
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
2011年07月29日 12:21:46 -04:00
- thou shalt order your imports by the full module path
2010年05月27日 23:05:26 -07:00
- thou shalt organize your imports according to the following template
::
# vim: tabstop=4 shiftwidth=4 softtabstop=4
2011年07月29日 12:21:46 -04:00
{{stdlib imports in human alphabetical order by module name}}
2010年05月27日 23:05:26 -07:00
\n
2011年07月29日 12:21:46 -04:00
{{nova imports in human alphabetical order by module name}}
2010年05月27日 23:05:26 -07:00
\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
2011年07月29日 12:21:46 -04:00
import nova.api.ec2
from nova.api import openstack
2010年05月27日 23:05:26 -07:00
from nova.auth import users
2011年07月29日 12:21:46 -04:00
import nova.flags
2010年05月27日 23:05:26 -07:00
from nova.endpoint import cloud
2011年07月29日 12:21:46 -04:00
from nova import test
Docstrings
----------
2011年03月28日 10:46:02 -07:00
"""A one line docstring looks like this and ends in a period."""
2011年03月28日 10:46:02 -07:00
"""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
2011年03月29日 11:15:16 -07:00
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.
2011年02月12日 13:30:31 -08:00
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/
2011年03月28日 10:46:02 -07:00
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
2011年07月29日 12:21:46 -04:00
:returns: return_type -- description of the return value
:raises: AttributeError, KeyError
"""
2011年07月29日 12:21:46 -04:00
Dictionaries/Lists
------------------
If a dictionary (dict) or list object is longer than 80 characters, its
items should be split with newlines. Embedded iterables should have their
items indented. Additionally, the last item in the dictionary should have
a trailing comma. This increases readability and simplifies future diffs.
Example:
my_dictionary = {
"image": {
"name": "Just a Snapshot",
"size": 2749573,
"properties": {
"user_id": 12,
"arch": "x86_64",
},
"things": [
"thing_one",
"thing_two",
],
"status": "ACTIVE",
},
}
Method Signatures
-----------------
Calls to methods 80 characters or longer should format each argument with
newlines. This is mainly for readability.
unnecessarily_long_function_name('string one',
'string two',
kwarg1=constants.ACTIVE,
kwarg2=['a', 'b', 'c'])
Rather than constructing parameters inline, it is better to break things up:
list_of_strings = [
'what_a_long_string',
'not as long',
]
dict_of_numbers = {
'one': 1,
'two': 2,
'twenty four': 24,
}
object_one.call_a_method('string three',
'string four',
kwarg1=list_of_strings,
kwarg2=dict_of_numbers)