/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/deadly-sins.txt

  • Committer: Martin Pool
  • Date: 2005-08-24 08:59:32 UTC
  • Revision ID: mbp@sourcefrog.net-20050824085932-c61f1f1f1c930e13
- Add a simple UIFactory 

  The idea of this is to let a client of bzrlib set some 
  policy about how output is displayed.

  In this revision all that's done is that progress bars
  are constructed by a policy established by the application
  rather than being randomly constructed in the library 
  or passed down the calls.  This avoids progress bars
  popping up while running the test suite and cleans up
  some code.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/deadly-sins.txt
 
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