|
1048
by Martin Pool
- basic rules for hacking bzr |
1 |
guidelines for modifying bzr |
2 |
============================
|
|
3 |
||
4 |
* New functionality should have test cases. Preferably write the |
|
5 |
test before writing the code. |
|
6 |
||
7 |
In general, you can test at either the command-line level or the |
|
8 |
internal API level. Choose whichever is appropriate: if adding a |
|
9 |
new command, or a new command option, then call through run_bzr(). |
|
10 |
It is not necessary to do both. |
|
11 |
||
12 |
* Before fixing a bug, write a test case so that it does not regress. |
|
13 |
||
14 |
* Exceptions should be defined inside bzrlib.errors, so that we can |
|
15 |
see the whole tree at a glance. |
|
16 |
||
17 |
* Imports should be done at the top-level of the file, unless there is |
|
18 |
a strong reason to have them lazily loaded when a particular |
|
19 |
function runs. Import statements have a cost, so try to make sure |
|
20 |
they don't run inside hot functions. |
|
21 |
||
22 |
* Please write PEP-8__ compliant code.
|
|
23 |
||
24 |
__ http://www.python.org/peps/pep-0008.html
|
|
25 |
||
26 |
* Module names should always be given fully-qualified,
|
|
27 |
i.e. ``bzrlib.hashcache`` not just ``hashcache``.
|