1
***********************
2
Bazaar Code Style Guide
3
***********************
8
Please write PEP-8__ compliant code.
10
__ http://www.python.org/peps/pep-0008.html
12
One often-missed requirement is that the first line of docstrings
13
should be a self-contained one-sentence summary.
15
We use 4 space indents for blocks, and never use tab characters. (In vim,
18
Trailing white space should be avoided, but is allowed.
19
You should however not make lots of unrelated white space changes.
21
Unix style newlines (LF) are used.
23
Each file must have a newline at the end of it.
25
Lines should be no more than 79 characters if at all possible.
26
Lines that continue a long statement may be indented in either of
29
within the parenthesis or other character that opens the block, e.g.::
35
or indented by four spaces::
41
The first is considered clearer by some people; however it can be a bit
42
harder to maintain (e.g. when the method name changes), and it does not
43
work well if the relevant parenthesis is already far to the right. Avoid
46
self.legbone.kneebone.shinbone.toebone.shake_it(one,
52
self.legbone.kneebone.shinbone.toebone.shake_it(one,
58
self.legbone.kneebone.shinbone.toebone.shake_it(
61
For long lists, we like to add a trailing comma and put the closing
62
character on the following line. This makes it easier to add new items in
65
from bzrlib.goo import (
71
There should be spaces between function parameters, but not between the
72
keyword name and the value::
74
call(1, 3, cheese=quark)
80
Bazaar supports Python from 2.6 through 2.7, and in the future we want to
81
support Python 3. Avoid using language features added in
82
2.7, or features deprecated in Python 3.0. (You can check v3
83
compatibility using the ``-3`` option of Python2.6.)
89
``hasattr`` should not be used because it swallows exceptions including
90
``KeyboardInterrupt``. Instead, say something like ::
92
if getattr(thing, 'name', None) is None
98
``**kwargs`` in the prototype of a function should be used sparingly.
99
It can be good on higher-order functions that decorate other functions,
100
such as ``addCleanup`` or ``assertRaises``, or on functions that take only
101
(or almost only) kwargs, where any kwargs can be passed.
103
Otherwise, be careful: if the parameters to a function are a bit complex
104
and might vary over time (e.g. the ``commit`` API) then we prefer to pass an
105
object rather than a bag of positional and/or keyword args. If you have
106
an arbitrary set of keys and values that are different with each use (e.g.
107
string interpolation inputs) then again that should not be mixed in with
108
the regular positional/keyword args, it seems like a different category of
112
Imitating standard objects
113
==========================
115
Don't provide methods that imitate built-in classes (eg ``__in__``,
116
``__call__``, ``__int__``, ``__getitem__``) unless the class you're
117
implementing really does act like the builtin class, in semantics and
120
For example, old code lets you say ``file_id in inv`` but we no longer
121
consider this good style. Instead, say more explicitly
122
``inv.has_id(file_id)``.
124
``__repr__``, ``__cmp__``, ``__str__`` are usually fine.
130
* Imports should be done at the top-level of the file, unless there is
131
a strong reason to have them lazily loaded when a particular
132
function runs. Import statements have a cost, so try to make sure
133
they don't run inside hot functions.
135
* Module names should always be given fully-qualified,
136
i.e. ``bzrlib.hashcache`` not just ``hashcache``.
142
Functions, methods or members that are relatively private are given
143
a leading underscore prefix. Names without a leading underscore are
144
public not just across modules but to programmers using bzrlib as an
147
We prefer class names to be concatenated capital words (``TestCase``)
148
and variables, methods and functions to be lowercase words joined by
149
underscores (``revision_id``, ``get_revision``).
151
For the purposes of naming some names are treated as single compound
152
words: "filename", "revno".
154
Consider naming classes as nouns and functions/methods as verbs.
156
Try to avoid using abbreviations in names, because there can be
157
inconsistency if other people use the full name.
163
``revision_id`` not ``rev_id`` or ``revid``
165
Functions that transform one thing to another should be named ``x_to_y``
166
(not ``x2y`` as occurs in some old code.)
172
Python destructors (``__del__``) work differently to those of other
173
languages. In particular, bear in mind that destructors may be called
174
immediately when the object apparently becomes unreferenced, or at some
175
later time, or possibly never at all. Therefore we have restrictions on
176
what can be done inside them.
178
0. If you think you need to use a ``__del__`` method ask another
179
developer for alternatives. If you do need to use one, explain
182
1. Never rely on a ``__del__`` method running. If there is code that
183
must run, instead have a ``finally`` block or an ``addCleanup`` call an
184
explicit ``close`` method.
186
2. Never ``import`` from inside a ``__del__`` method, or you may crash the
189
3. Prior to bzr 2.4, we sometimes used to raise warnings from del methods
190
that the object was not cleaned up or closed. We no longer do this:
191
failure to close the object doesn't cause a test failure; the warning
192
appears an arbitrary long time after the problem occurred (the object
193
being leaked); merely having a del method inhibits Python gc; the
194
warnings appear to users and upset them; they can also break tests that
195
are checking what appears on stderr.
197
In short, just don't use ``__del__``.
202
Often when something has failed later code will fail too, including
203
cleanups invoked from ``finally`` blocks. These secondary failures are
204
generally uninteresting compared to the original exception. ``bzrlib``
205
has some facilities you can use to mitigate this.
207
* In ``Command`` subclasses, prefer the ``add_cleanup`` method to using
208
``try``/``finally`` blocks. E.g. to acquire a lock and ensure it will
209
always be released when the command is done::
211
self.add_cleanup(branch.lock_read().unlock)
213
This also avoids heavily indented code. It also makes it easier to notice
214
mismatched lock/unlock pairs (and other kinds of resource
215
acquire/release) because there isn't a large block of code separating
218
* Use the ``only_raises`` decorator (from ``bzrlib.decorators``) when
219
defining methods that are typically called in ``finally`` blocks, such
220
as ``unlock`` methods. For example, ``@only_raises(LockNotHeld,
221
LockBroken)``. All errors that are unlikely to be a knock-on failure
222
from a previous failure should be allowed.
224
* Consider using the ``OperationWithCleanups`` helper from
225
``bzrlib.cleanup`` anywhere else you have a ``finally`` block that
232
In some places we have variables which point to callables that construct
233
new instances. That is to say, they can be used a lot like class objects,
234
but they shouldn't be *named* like classes. Things called ``FooBar`` should
235
create an instance of ``FooBar``. A factory method that might create a
236
``FooBar`` or might make something else should be called ``foo_factory``.
242
Several places in Bazaar use (or will use) a registry, which is a
243
mapping from names to objects or classes. The registry allows for
244
loading in registered code only when it's needed, and keeping
245
associated information such as a help string or description.
248
InterObject and multiple dispatch
249
=================================
251
The ``InterObject`` provides for two-way `multiple dispatch`__: matching
252
up for example a source and destination repository to find the right way
253
to transfer data between them.
255
.. __: http://en.wikipedia.org/wiki/Multiple_dispatch
257
There is a subclass ``InterObject`` classes for each type of object that is
258
dispatched this way, e.g. ``InterRepository``. Calling ``.get()`` on this
259
class will return an ``InterObject`` instance providing the best match for
260
those parameters, and this instance then has methods for operations
265
inter = InterRepository.get(source_repo, target_repo)
266
inter.fetch(revision_id)
268
``InterRepository`` also acts as a registry-like object for its
269
subclasses, and they can be added through ``.register_optimizer``. The
270
right one to run is selected by asking each class, in reverse order of
271
registration, whether it ``.is_compatible`` with the relevant objects.
276
To make startup time faster, we use the ``bzrlib.lazy_import`` module to
277
delay importing modules until they are actually used. ``lazy_import`` uses
278
the same syntax as regular python imports. So to import a few modules in a
281
from bzrlib.lazy_import import lazy_import
282
lazy_import(globals(), """
291
revision as _mod_revision,
293
import bzrlib.transport
297
At this point, all of these exist as a ``ImportReplacer`` object, ready to
298
be imported once a member is accessed. Also, when importing a module into
299
the local namespace, which is likely to clash with variable names, it is
300
recommended to prefix it as ``_mod_<module>``. This makes it clearer that
301
the variable is a module, and these object should be hidden anyway, since
302
they shouldn't be imported into other namespaces.
304
While it is possible for ``lazy_import()`` to import members of a module
305
when using the ``from module import member`` syntax, it is recommended to
306
only use that syntax to load sub modules ``from module import submodule``.
307
This is because variables and classes can frequently be used without
308
needing a sub-member for example::
310
lazy_import(globals(), """
311
from module import MyClass
315
return isinstance(x, MyClass)
317
This will incorrectly fail, because ``MyClass`` is a ``ImportReplacer``
318
object, rather than the real class.
320
It also is incorrect to assign ``ImportReplacer`` objects to other variables.
321
Because the replacer only knows about the original name, it is unable to
322
replace other variables. The ``ImportReplacer`` class will raise an
323
``IllegalUseOfScopeReplacer`` exception if it can figure out that this
324
happened. But it requires accessing a member more than once from the new
325
variable, so some bugs are not detected right away.
331
The null revision is the ancestor of all revisions. Its revno is 0, its
332
revision-id is ``null:``, and its tree is the empty tree. When referring
333
to the null revision, please use ``bzrlib.revision.NULL_REVISION``. Old
334
code sometimes uses ``None`` for the null revision, but this practice is
338
Object string representations
339
=============================
341
Python prints objects using their ``__repr__`` method when they are
342
written to logs, exception tracebacks, or the debugger. We want
343
objects to have useful representations to help in determining what went
346
If you add a new class you should generally add a ``__repr__`` method
347
unless there is an adequate method in a parent class. There should be a
350
Representations should typically look like Python constructor syntax, but
351
they don't need to include every value in the object and they don't need
352
to be able to actually execute. They're to be read by humans, not
353
machines. Don't hardcode the classname in the format, so that we get the
354
correct value if the method is inherited by a subclass. If you're
355
printing attributes of the object, including strings, you should normally
356
use ``%r`` syntax (to call their repr in turn).
358
Try to avoid the representation becoming more than one or two lines long.
359
(But balance this against including useful information, and simplicity of
362
Because repr methods are often called when something has already gone
363
wrong, they should be written somewhat more defensively than most code.
364
They shouldn't have side effects like doing network or disk
366
The object may be half-initialized or in some other way in an illegal
367
state. The repr method shouldn't raise an exception, or it may hide the
368
(probably more useful) underlying exception.
373
return '%s(%r)' % (self.__class__.__name__,
380
A bare ``except`` statement will catch all exceptions, including ones that
381
really should terminate the program such as ``MemoryError`` and
382
``KeyboardInterrupt``. They should rarely be used unless the exception is
383
later re-raised. Even then, think about whether catching just
384
``Exception`` (which excludes system errors in Python2.5 and later) would
387
The ``__str__`` method on exceptions should be small and have no side
388
effects, following the rules given for `Object string representations`_.
389
In particular it should not do any network IO, or complicated
390
introspection of other objects. All the state needed to present the
391
exception to the user should be gathered before the error is raised.
392
In other words, exceptions should basically be value objects.
398
All code should be exercised by the test suite. See the `Bazaar Testing
399
Guide <http://doc.bazaar.canonical.com/developers/testing.html>`_ for detailed
400
information about writing tests.
406
Do not use the Python ``assert`` statement, either in tests or elsewhere.
407
A source test checks that it is not used. It is ok to explicitly raise
412
* It makes the behaviour vary depending on whether bzr is run with -O
413
or not, therefore giving a chance for bugs that occur in one case or
414
the other, several of which have already occurred: assertions with
415
side effects, code which can't continue unless the assertion passes,
416
cases where we should give the user a proper message rather than an
418
* It's not that much shorter than an explicit if/raise.
419
* It tends to lead to fuzzy thinking about whether the check is
420
actually needed or not, and whether it's an internal error or not
421
* It tends to cause look-before-you-leap patterns.
422
* It's unsafe if the check is needed to protect the integrity of the
424
* It tends to give poor messages since the developer can get by with
425
no explanatory text at all.
426
* We can't rely on people always running with -O in normal use, so we
427
can't use it for tests that are actually expensive.
428
* Expensive checks that help developers are better turned on from the
429
test suite or a -D flag.
430
* If used instead of ``self.assert*()`` in tests it makes them falsely
438
;(defface my-invalid-face
439
; '((t (:background "Red" :underline t)))
440
; "Face used to highlight invalid constructs or other uglyties"
443
(defun my-python-mode-hook ()
444
;; setup preferred indentation style.
445
(setq fill-column 79)
446
(setq indent-tabs-mode nil) ; no tabs, never, I will not repeat
447
; (font-lock-add-keywords 'python-mode
448
; '(("^\\s *\t" . 'my-invalid-face) ; Leading tabs
449
; ("[ \t]+$" . 'my-invalid-face) ; Trailing spaces
450
; ("^[ \t]+$" . 'my-invalid-face)); Spaces only
454
(add-hook 'python-mode-hook 'my-python-mode-hook)
456
The lines beginning with ';' are comments. They can be activated
457
if one want to have a strong notice of some tab/space usage
463
The ``bzrlib.osutils`` module has many useful helper functions, including
464
some more portable variants of functions in the standard library.
466
In particular, don't use ``shutil.rmtree`` unless it's acceptable for it
467
to fail on Windows if some files are readonly or still open elsewhere.
468
Use ``bzrlib.osutils.rmtree`` instead.
470
Using the ``open(..).read(..)`` or ``open(..).write(..)`` style chaining
471
of methods for reading or writing file content relies on garbage collection
472
to close the file which may keep the file open for an undefined period of
473
time. This may break some follow up operations like rename on Windows.
474
Use ``try/finally`` to explictly close the file. E.g.::
476
f = open('foo.txt', 'w')
486
Bazaar is a GNU project and uses standard GNU terminology, especially:
488
* Use the word "Linux" to refer to the Linux kernel, not as a synechoche
489
for the entire operating system. (See `bug 528253
490
<https://bugs.launchpad.net/bzr/+bug/528253>`_).
492
* Don't say "open source" when you mean "free software".
498
If you need to import a module (or attribute of a module) named in a
501
* If importing a module, not an attribute, and the module is a top-level
502
module (i.e. has no dots in the name), then it's ok to use the builtin
503
``__import__``, e.g. ``__import__(module_name)``.
504
* In all other cases, prefer ``bzrlib.pyutils.get_named_object`` to the
505
built-in ``__import__``. ``__import__`` has some subtleties and
506
unintuitive behaviours that make it hard to use correctly.
added
removed
doc/developers/code-style.txt
