1
**************************
2
Deadly sins in tool design
3
**************************
5
http://gcc.gnu.org/wiki/DeadlySins
7
They don't directly apply, but many do correspond.
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.
13
1. to code before you think.
15
2. to assume the user has all the knowledge the compiler writer has.
17
3. to not write proper documentation.
19
4. to ignore language standards.
21
5. to treat error diagnosis as an afterthought.
23
6. to equate the unlikely with the impossible.
25
7. to make the encoding of the compiler dependent on its data formats.
27
8. to use numbers for objects that are not numbers.
29
9. to pretend you are catering to everyone at the same time.
31
10. to have no strategy for processing break-ins.
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).)
40
(Perhaps this corresponds to handling user interrupts during
41
operation -- they should not leave anything in an inconsistent
44
11. to rate the beauty of mathematics above the usability of your
47
12. to let any error go undetected.
49
13. to leave users to find the errors in your compiler.
added
removed
doc/deadly-sins.txt
