1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
These rules are fairly standard and boring. People will bitch about something
in here, no doubt. Get over it. Much of this was stolen from the Linux Kernel
coding style, because most of it makes good sense. If you disagree, that's OK,
but please stick to the rules anyway ;-)
Language
Please use Python where possible. It's not the ideal language for everything,
but it's pretty good, and consistency goes a long way in making the project
maintainable. (Obviously using C or whatever for writing tests is fine).
Base coding style
When writing python code, unless otherwise stated, stick to the python style
guide (http://www.python.org/dev/peps/pep-0008/).
Indentation & whitespace
Format your code for an 80 character wide screen.
Indentation is now 4 spaces, as opposed to hard tabs (which it used to be).
This is the Python standard.
Don't leave trailing whitespace, or put whitespace on blank lines.
Leave TWO blank lines between functions - this is Python, there are no clear
function end markers, and we need help.
Variable names and UpPeR cAsE
Use descriptive variable names where possible - it helps to make the code
self documenting.
Don't use CamelCaps style in most places - use underscores to separate parts
of your variable_names please. I shall make a bedgrudging exception for class
names I suppose, but I'll still whine about it a lot.
Importing modules
The order of imports should be as follows:
Standard python modules
Non-standard python modules
Autotest modules
Within one of these three sections, all module imports using the from
keyword should appear after regular imports.
Modules should be lumped together on the same line.
Wildcard imports (from x import *) should be avoided if possible.
Classes should not be imported from modules, but modules may be imported
from packages, i.e.:
from common_lib import error
and not
from common_lib.error import AutoservError
For example:
import os, pickle, random, re, select, shutil, signal, StringIO, subprocess
import sys, time, urllib, urlparse
import common # Magic autotest_lib module and sys.path setup code.
import MySQLdb # After common so that we check our site-packages first.
from common_lib import error
Testing None
Use "is None" rather than "== None" and "is not None" rather than "!= None".
This way you'll never run into a case where someone's __eq__ or __ne__
method do the wrong thing
Comments
Generally, you want your comments to tell WHAT your code does, not HOW.
We can figure out how from the code itself (or if not, your code needs fixing).
Try to describle the intent of a function and what it does in a triple-quoted
(multiline) string just after the def line. We've tried to do that in most
places, though undoubtedly we're not perfect. A high level overview is
incredibly helpful in understanding code.
Simple code
Keep it simple; this is not the right place to show how smart you are. We
have plenty of system failures to deal with without having to spend ages
figuring out your code, thanks ;-) Readbility, readability, readability.
I really don't care if other things are more compact.
"Debugging is twice as hard as writing the code in the first place. Therefore,
if you write the code as cleverly as possible, you are, by definition, not
smart enough to debug it." Brian Kernighan
Function length
Please keep functions short, under 30 lines or so if possible. Even though
you are amazingly clever, and can cope with it, the rest of us are all stupid,
so be nice and help us out. To quote the Linux Kernel coding style:
Functions should be short and sweet, and do just one thing. They should
fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
as we all know), and do one thing and do that well.
Exceptions
When raising exceptions, the preferred syntax for it is:
raise FooException('Exception Message')
Please don't raise string exceptions, as they're deprecated and will be removed
from future versions of python. If you're in doubt about what type of exception
you will raise, please look at http://docs.python.org/lib/module-exceptions.html
and client/common_lib/error.py, the former is a list of python built in
exceptions and the later is a list of autotest/autoserv internal exceptions. Of
course, if you really need to, you can extend the exception definitions on
client/common_lib/error.py.
Submitting patches
Generate universal diffs. Email them to autotest@test.kernel.org.
Most mailers now break lines and/or changes tabs to spaces. If you know how
to avoid that - great, put your patches inline. If you're not sure, just
attatch them, I don't care much. Please base them off the current version.
Don't worry about submitting patches to a public list - everybody makes
mistakes, especially me ... so get over it and don't worry about it.
(though do give your changes a test first ;-))
|
