|
974.1.26
by aaron.bentley at utoronto
merged mbp@sourcefrog.net-20050817233101-0939da1cf91f2472 |
1 |
============================
|
2 |
guidelines for modifying bzr |
|
3 |
============================
|
|
4 |
||
5 |
* New functionality should have test cases. Preferably write the |
|
6 |
test before writing the code. |
|
7 |
||
8 |
In general, you can test at either the command-line level or the |
|
9 |
internal API level. Choose whichever is appropriate: if adding a |
|
10 |
new command, or a new command option, then call through run_bzr(). |
|
11 |
It is not necessary to do both. |
|
12 |
||
13 |
* Before fixing a bug, write a test case so that it does not regress. |
|
14 |
||
15 |
* Exceptions should be defined inside bzrlib.errors, so that we can |
|
16 |
see the whole tree at a glance. |
|
17 |
||
18 |
* Imports should be done at the top-level of the file, unless there is |
|
19 |
a strong reason to have them lazily loaded when a particular |
|
20 |
function runs. Import statements have a cost, so try to make sure |
|
21 |
they don't run inside hot functions. |
|
22 |
||
23 |
* Please write PEP-8__ compliant code. |
|
24 |
||
25 |
__ http://www.python.org/peps/pep-0008.html |
|
26 |
||
27 |
* Module names should always be given fully-qualified, |
|
28 |
i.e. ``bzrlib.hashcache`` not just ``hashcache``. |
|
29 |
||
30 |
||
31 |
||
32 |
Documentation
|
|
33 |
=============
|
|
34 |
||
35 |
If you change the behaviour of a command, please update its docstring |
|
36 |
in bzrlib/commands.py. This is displayed by the 'bzr help' command. |
|
37 |
||
38 |
If you make a user-visible change, please add a note to the NEWS file. |
|
39 |
The description should be written to make sense to someone who's just |
|
40 |
a user of bzr, not a developer: new functions or classes shouldn't be |
|
41 |
mentioned, but new commands, changes in behaviour or fixed nontrivial |
|
42 |
bugs should be listed. See the existing entries for an idea of what |
|
43 |
should be done. |