~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/code-style.txt

(spiv) Add docstrings to AbstractSearch and AbstractSearchResult. (Andrew
 Bennetts)

Show diffs side-by-side

added added

removed removed

Lines of Context:
78
78
===============
79
79
 
80
80
Bazaar supports Python from 2.4 through 2.6, and in the future we want to
81
 
support Python 3.0.  Avoid using language features added in 2.5 or 2.6, or
82
 
features deprecated in Python 3.0.  (You can check v3 compatibility using
83
 
the ``-3`` option of Python2.6.)
 
81
support Python 2.7 and 3.0.  Avoid using language features added in 2.5,
 
82
2.6 or 2.7, or features deprecated in Python 3.0.  (You can check v3
 
83
compatibility using the ``-3`` option of Python2.6.)
84
84
 
85
85
Specifically:
86
86
 
101
101
  if getattr(thing, 'name', None) is None
102
102
 
103
103
 
 
104
kwargs
 
105
======
 
106
 
 
107
``**kwargs`` in the prototype of a function should be used sparingly.
 
108
It can be good on higher-order functions that decorate other functions,
 
109
such as ``addCleanup`` or ``assertRaises``, or on functions that take only
 
110
(or almost only) kwargs, where any kwargs can be passed.  
 
111
 
 
112
Otherwise, be careful: if the parameters to a function are a bit complex
 
113
and might vary over time (e.g.  the ``commit`` API) then we prefer to pass an
 
114
object rather than a bag of positional and/or keyword args.  If you have
 
115
an arbitrary set of keys and values that are different with each use (e.g.
 
116
string interpolation inputs) then again that should not be mixed in with
 
117
the regular positional/keyword args, it seems like a different category of
 
118
thing.
 
119
 
 
120
 
 
121
Imitating standard objects
 
122
==========================
 
123
 
 
124
Don't provide methods that imitate built-in classes (eg ``__in__``,
 
125
``__call__``, ``__int__``, ``__getitem__``) unless the class you're
 
126
implementing really does act like the builtin class, in semantics and
 
127
performance.
 
128
 
 
129
For example, old code lets you say ``file_id in inv`` but we no longer
 
130
consider this good style.  Instead, say more explicitly
 
131
``inv.has_id(file_id)``.
 
132
 
 
133
``__repr__``, ``__cmp__``, ``__str__`` are usually fine.
 
134
 
 
135
 
104
136
Module Imports
105
137
==============
106
138
 
332
364
 
333
365
Because repr methods are often called when something has already gone
334
366
wrong, they should be written somewhat more defensively than most code.
 
367
They shouldn't have side effects like doing network or disk
 
368
IO.
335
369
The object may be half-initialized or in some other way in an illegal
336
370
state.  The repr method shouldn't raise an exception, or it may hide the
337
371
(probably more useful) underlying exception.
353
387
``Exception`` (which excludes system errors in Python2.5 and later) would
354
388
be better.
355
389
 
 
390
The ``__str__`` method on exceptions should be small and have no side
 
391
effects, following the rules given for `Object string representations`_.
 
392
In particular it should not do any network IO, or complicated
 
393
introspection of other objects.  All the state needed to present the
 
394
exception to the user should be gathered before the error is raised.
 
395
In other words, exceptions should basically be value objects.
 
396
 
356
397
 
357
398
Test coverage
358
399
=============
453
494
 
454
495
 * Don't say "open source" when you mean "free software".
455
496
 
 
497
 
 
498
Dynamic imports
 
499
===============
 
500
 
 
501
If you need to import a module (or attribute of a module) named in a
 
502
variable:
 
503
 
 
504
 * If importing a module, not an attribute, and the module is a top-level
 
505
   module (i.e. has no dots in the name), then it's ok to use the builtin
 
506
   ``__import__``, e.g. ``__import__(module_name)``.
 
507
 * In all other cases, prefer ``bzrlib.pyutils.get_named_object`` to the
 
508
   built-in ``__import__``.  ``__import__`` has some subtleties and
 
509
   unintuitive behaviours that make it hard to use correctly.
 
510
 
456
511
..
457
512
   vim: ft=rst tw=74 ai