~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to HACKING

  • Committer: Martin Pool
  • Date: 2005-08-05 20:00:14 UTC
  • Revision ID: mbp@sourcefrog.net-20050805200014-75236893f666c4bb
- basic rules for hacking bzr

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
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``.
 
 
b'\\ No newline at end of file'