|
6
by mbp at sourcefrog
import all docs from arch |
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 |