~bzr-pqm/bzr/bzr.dev : contents of HACKING at revision 1092.1.14

~bzr-pqm/bzr/bzr.dev : (revision 1092.1.14)

============================
guidelines for modifying bzr
============================

* New functionality should have test cases.  Preferably write the
  test before writing the code.

  In general, you can test at either the command-line level or the
  internal API level.  Choose whichever is appropriate: if adding a
  new command, or a new command option, then call through run_bzr().
  It is not necessary to do both.

* Before fixing a bug, write a test case so that it does not regress.

* Exceptions should be defined inside bzrlib.errors, so that we can
  see the whole tree at a glance.

* Imports should be done at the top-level of the file, unless there is
  a strong reason to have them lazily loaded when a particular
  function runs.  Import statements have a cost, so try to make sure
  they don't run inside hot functions.

* Please write PEP-8__ compliant code.

__ http://www.python.org/peps/pep-0008.html

* Module names should always be given fully-qualified,
  i.e. ``bzrlib.hashcache`` not just ``hashcache``.



Documentation
=============

If you change the behaviour of a command, please update its docstring
in bzrlib/commands.py.  This is displayed by the 'bzr help' command.

If you make a user-visible change, please add a note to the NEWS file.
The description should be written to make sense to someone who's just
a user of bzr, not a developer: new functions or classes shouldn't be
mentioned, but new commands, changes in behaviour or fixed nontrivial
bugs should be listed.  See the existing entries for an idea of what
should be done.

1067 by Martin Pool - note for contributors to please update the NEWS file	1	============================
1048 by Martin Pool - basic rules for hacking bzr	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,
1067 by Martin Pool - note for contributors to please update the NEWS file	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.