~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/deadly-sins.txt

  • Committer: Vincent Ladeuil
  • Date: 2007-10-24 13:56:34 UTC
  • mto: (3928.1.1 bzr.integration)
  • mto: This revision was merged to the branch mainline in revision 3929.
  • Revision ID: v.ladeuil+lp@free.fr-20071024135634-d8os3by1g6f45q12
Fix python2.6 deprecation warnings (still 4 failures 5 errors in test suite).

* bzrlib/osutils.py: 
Wrap md5 and sha imports to be compatible with python 2.4, 2.5,
2.6.
Replace all sha.new() calls by sha() calls they are reputedly
faster (not profiled).

* bzrlib/weave.py: 
Update sha import, fix use.     

* bzrlib/transport/http/_urllib2_wrappers.py: 
Update sha and md5 imports, fix uses.

* bzrlib/tests/test_testament.py: 
Update sha import.

* bzrlib/tests/test_knit.py: 
Update sha import, fix uses.    

* bzrlib/tests/test_hashcache.py: 
Update sha import, fix use.     

* bzrlib/tests/repository_implementations/test_check_reconcile.py: 
Update sha import, fix use.     

* bzrlib/tests/HTTPTestUtil.py: 
Update md5 import, fix uses. Delete useless sha import.

* bzrlib/testament.py: 
Update sha import.

* bzrlib/hashcache.py: 
Update sha import.

* bzrlib/revisionspec.py:
(RevisionSpec.__new__): Remove useless parameters since python2.6
is stricter.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
**************************
2
 
Deadly sins in tool design
3
 
**************************
4
 
 
5
 
http://gcc.gnu.org/wiki/DeadlySins
6
 
 
7
 
They don't directly apply, but many do correspond.
8
 
 
9
 
  The "Deadly Sins" from P. J. Brown's *Writing Interactive Compilers and Interpreters*, Wiley 1979. We've committed them all at least once in GCC.
10
 
 
11
 
  The deadly sins are:
12
 
 
13
 
  1. to code before you think.
14
 
 
15
 
  2. to assume the user has all the knowledge the compiler writer has.
16
 
 
17
 
  3. to not write proper documentation.
18
 
 
19
 
  4. to ignore language standards.
20
 
 
21
 
  5. to treat error diagnosis as an afterthought.
22
 
 
23
 
  6. to equate the unlikely with the impossible.
24
 
 
25
 
  7. to make the encoding of the compiler dependent on its data formats.
26
 
 
27
 
  8. to use numbers for objects that are not numbers.
28
 
 
29
 
  9. to pretend you are catering to everyone at the same time.
30
 
 
31
 
  10. to have no strategy for processing break-ins.
32
 
 
33
 
      (A break-in is when you interrupt an interactive compiler, and
34
 
      then possibly continue it later. This is meaningful in an
35
 
      environment in which the compiler is run dynamically, such as
36
 
      many LISP and some BASIC environments. It is not meaningful for
37
 
      typical uses of C/C++ (although there was at least one
38
 
      interactive C environment, from Sabre).)
39
 
 
40
 
      (Perhaps this corresponds to handling user interrupts during
41
 
      operation -- they should not leave anything in an inconsistent
42
 
      state.)
43
 
 
44
 
  11. to rate the beauty of mathematics above the usability of your
45
 
      compiler.
46
 
 
47
 
  12. to let any error go undetected.
48
 
 
49
 
  13. to leave users to find the errors in your compiler.
50