1
by Jesse Andrews
initial commit |
1 |
Nova Style Commandments |
2 |
=======================
|
|
3 |
||
4 |
Step 1: Read http://www.python.org/dev/peps/pep-0008/ |
|
5 |
Step 2: Read http://www.python.org/dev/peps/pep-0008/ again |
|
6 |
Step 3: Read on |
|
7 |
||
1343.2.3
by Brian Waldon
upgrades |
8 |
|
9 |
General
|
|
10 |
-------
|
|
1343.2.4
by Brian Waldon
one last change |
11 |
- Put two newlines between top-level code (funcs, classes, etc) |
12 |
- Put one newline between methods in classes and anywhere else |
|
1343.2.3
by Brian Waldon
upgrades |
13 |
- Do not write "except:", use "except Exception:" at the very least |
1343.2.4
by Brian Waldon
one last change |
14 |
- Include your name with TODOs as in "#TODO(termie)" |
15 |
- Do not name anything the same name as a built-in or reserved word |
|
1343.2.3
by Brian Waldon
upgrades |
16 |
|
17 |
||
1
by Jesse Andrews
initial commit |
18 |
Imports
|
19 |
-------
|
|
1343.2.3
by Brian Waldon
upgrades |
20 |
- Do not import objects, only modules |
21 |
- Do not import more than one module per line |
|
22 |
- Do not make relative imports |
|
23 |
- Order your imports by the full module path |
|
24 |
- Organize your imports according to the following template |
|
1
by Jesse Andrews
initial commit |
25 |
|
26 |
::
|
|
27 |
# vim: tabstop=4 shiftwidth=4 softtabstop=4
|
|
1343.2.10
by Brian Waldon
removing extra verbage |
28 |
{{stdlib imports in human alphabetical order}} |
1
by Jesse Andrews
initial commit |
29 |
\n
|
1343.2.10
by Brian Waldon
removing extra verbage |
30 |
{{nova imports in human alphabetical order}} |
1
by Jesse Andrews
initial commit |
31 |
\n
|
32 |
\n
|
|
33 |
{{begin your code}} |
|
34 |
||
35 |
||
36 |
Human Alphabetical Order Examples |
|
37 |
---------------------------------
|
|
38 |
::
|
|
39 |
import httplib |
|
40 |
import logging |
|
41 |
import random |
|
42 |
import StringIO |
|
43 |
import time |
|
44 |
import unittest |
|
45 |
||
1343.2.1
by Brian Waldon
updating HACKING |
46 |
import nova.api.ec2 |
47 |
from nova.api import openstack |
|
1
by Jesse Andrews
initial commit |
48 |
from nova.auth import users |
1343.2.1
by Brian Waldon
updating HACKING |
49 |
import nova.flags |
1
by Jesse Andrews
initial commit |
50 |
from nova.endpoint import cloud |
1343.2.1
by Brian Waldon
updating HACKING |
51 |
from nova import test |
641.3.1
by termie
some updates to HACKING to describe the docstrings |
52 |
|
1343.2.2
by Brian Waldon
expanding |
53 |
|
641.3.1
by termie
some updates to HACKING to describe the docstrings |
54 |
Docstrings
|
55 |
----------
|
|
897.3.1
by termie
HACKING update for docstrings |
56 |
"""A one line docstring looks like this and ends in a period."""
|
57 |
||
58 |
||
59 |
"""A multiline docstring has a one-line summary, less than 80 characters.
|
|
60 |
||
61 |
Then a new paragraph after a newline that explains in more detail any
|
|
62 |
general information about the function, class or method. Example usages
|
|
897.3.2
by termie
accidentally dropped a sentence |
63 |
are also great to have here if it is a complex class for function. After
|
64 |
you have finished your descriptions add an extra newline and close the
|
|
65 |
quotations.
|
|
641.3.1
by termie
some updates to HACKING to describe the docstrings |
66 |
|
641.3.2
by termie
fix :returns: and add pep-0257 |
67 |
When writing the docstring for a class, an extra line should be placed
|
68 |
after the closing quotations. For more in-depth explanations for these
|
|
69 |
decisions see http://www.python.org/dev/peps/pep-0257/
|
|
70 |
||
897.3.1
by termie
HACKING update for docstrings |
71 |
If you are going to describe parameters and return values, use Sphinx, the
|
72 |
appropriate syntax is as follows.
|
|
73 |
||
641.3.1
by termie
some updates to HACKING to describe the docstrings |
74 |
:param foo: the foo parameter
|
75 |
:param bar: the bar parameter
|
|
1343.2.1
by Brian Waldon
updating HACKING |
76 |
:returns: return_type -- description of the return value
|
1343.2.8
by Brian Waldon
adding more on return_type in docstrings |
77 |
:returns: description of the return value
|
1343.2.1
by Brian Waldon
updating HACKING |
78 |
:raises: AttributeError, KeyError
|
641.3.1
by termie
some updates to HACKING to describe the docstrings |
79 |
|
80 |
"""
|
|
1343.2.1
by Brian Waldon
updating HACKING |
81 |
|
1343.2.2
by Brian Waldon
expanding |
82 |
|
1343.2.1
by Brian Waldon
updating HACKING |
83 |
Dictionaries/Lists |
84 |
------------------
|
|
85 |
If a dictionary (dict) or list object is longer than 80 characters, its |
|
86 |
items should be split with newlines. Embedded iterables should have their |
|
87 |
items indented. Additionally, the last item in the dictionary should have |
|
88 |
a trailing comma. This increases readability and simplifies future diffs. |
|
89 |
||
90 |
Example: |
|
91 |
||
92 |
my_dictionary = { |
|
93 |
"image": { |
|
94 |
"name": "Just a Snapshot", |
|
95 |
"size": 2749573, |
|
96 |
"properties": { |
|
97 |
"user_id": 12, |
|
98 |
"arch": "x86_64", |
|
99 |
},
|
|
100 |
"things": [ |
|
101 |
"thing_one", |
|
102 |
"thing_two", |
|
103 |
],
|
|
104 |
"status": "ACTIVE", |
|
105 |
},
|
|
106 |
}
|
|
1343.2.2
by Brian Waldon
expanding |
107 |
|
108 |
||
109 |
Calling Methods |
|
110 |
---------------
|
|
1343.2.1
by Brian Waldon
updating HACKING |
111 |
Calls to methods 80 characters or longer should format each argument with |
1343.2.5
by Brian Waldon
rewording |
112 |
newlines. This is not a requirement, but a guideline. |
1343.2.1
by Brian Waldon
updating HACKING |
113 |
|
114 |
unnecessarily_long_function_name('string one', |
|
115 |
'string two', |
|
116 |
kwarg1=constants.ACTIVE, |
|
117 |
kwarg2=['a', 'b', 'c']) |
|
118 |
||
119 |
||
120 |
Rather than constructing parameters inline, it is better to break things up: |
|
121 |
||
122 |
list_of_strings = [ |
|
123 |
'what_a_long_string', |
|
124 |
'not as long', |
|
125 |
]
|
|
126 |
||
127 |
dict_of_numbers = { |
|
128 |
'one': 1, |
|
129 |
'two': 2, |
|
130 |
'twenty four': 24, |
|
131 |
}
|
|
132 |
||
133 |
object_one.call_a_method('string three', |
|
134 |
'string four', |
|
135 |
kwarg1=list_of_strings, |
|
136 |
kwarg2=dict_of_numbers) |
|
1343.2.2
by Brian Waldon
expanding |
137 |
|
1343.2.7
by Brian Waldon
removing 'Defining Methods' paragraph |
138 |
|
1343.2.2
by Brian Waldon
expanding |
139 |
Internationalization (i18n) Strings |
1343.2.11
by Brian Waldon
fixing underline |
140 |
-----------------------------------
|
1343.2.2
by Brian Waldon
expanding |
141 |
In order to support multiple languages, we have a mechanism to support |
142 |
automatic translations of exception and log strings. |
|
143 |
||
144 |
Example: |
|
145 |
msg = _("An error occurred") |
|
146 |
raise HTTPBadRequest(explanation=msg) |
|
147 |
||
148 |
If you have a variable to place within the string, first internationalize |
|
149 |
the template string then do the replacement. |
|
150 |
||
151 |
Example: |
|
152 |
msg = _("Missing parameter: %s") % ("flavor",) |
|
153 |
LOG.error(msg) |
|
154 |
||
155 |
If you have multiple variables to place in the string, use keyword |
|
156 |
parameters. This helps our translators reorder parameters when needed. |
|
157 |
||
158 |
Example: |
|
159 |
msg = _("The server with id %(s_id)s has no key %(m_key)s") |
|
1343.2.12
by Brian Waldon
typo |
160 |
LOG.error(msg % {"s_id": "1234", "m_key": "imageId"}) |