~bzr-pqm/bzr/bzr.dev

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
1098 by Martin Pool
- notes on how output is written
23
* Please write PEP-8__ compliant code.  
24
25
  One often-missed requirement is that the first line of docstrings
26
  should be a self-contained one-sentence summary.
974.1.26 by aaron.bentley at utoronto
merged mbp@sourcefrog.net-20050817233101-0939da1cf91f2472
27
28
__ http://www.python.org/peps/pep-0008.html
29
30
* Module names should always be given fully-qualified,
31
  i.e. ``bzrlib.hashcache`` not just ``hashcache``.
32
33
34
35
Documentation
36
=============
37
38
If you change the behaviour of a command, please update its docstring
39
in bzrlib/commands.py.  This is displayed by the 'bzr help' command.
40
41
If you make a user-visible change, please add a note to the NEWS file.
42
The description should be written to make sense to someone who's just
43
a user of bzr, not a developer: new functions or classes shouldn't be
44
mentioned, but new commands, changes in behaviour or fixed nontrivial
45
bugs should be listed.  See the existing entries for an idea of what
46
should be done.
1098 by Martin Pool
- notes on how output is written
47
48
49
50
Writing output
51
==============
52
53
(The strategy described here is what we want to get to, but it's not
54
consistently followed in the code at the moment.)
55
56
bzrlib is intended to be a generically reusable library.  It shouldn't
57
write messages to stdout or stderr, because some programs that use it
58
might want to display that information through a GUI or some other
59
mechanism.
60
61
We can distinguish two types of output from the library:
62
63
 1. Structured data representing the progress or result of an
64
    operation.  For example, for a commit command this will be a list
65
    of the modified files and the finally committed revision number
66
    and id.
67
68
    These should be exposed either through the return code or by calls
69
    to a callback parameter.
70
71
    A special case of this is progress indicators for long-lived
72
    operations, where the caller should pass a ProgressBar object.
73
74
 2. Unstructured log/debug messages, mostly for the benefit of the
75
    developers or users trying to debug problems.  This should always
76
    be sent through ``bzrlib.trace`` and Python ``logging``, so that
77
    it can be redirected by the client.
78
79
The distinction between the two is a bit subjective, but in general if
80
there is any chance that a library would want to see something as
81
structured data, we should make it so.
82
83
The policy about how output is presented in the text-mode client
84
should be only in the command-line tool.