; -*- fill-prefix: "    " -*-

TOM PROGRAMMING RULES

  1 [Tue Mar 5 00:36:08 1996, tiggr@tricky.es.ele.tue.nl] Do not use names
    for variables and other things which end up more-or-less literally in
    the C output, which resemble the name of existing things for the
    compiled C code.  For instance, it is a bad idea to name an instance
    variable `stdout'.

  2 [Mon Apr 1 13:14:01 1996, tiggr@tom.es.ele.tue.nl] The best available
    code beautifier is he who fires the programmer before that programmer
    gets a chance to write code needing a code beautifier.

  3 [Tue Jun 11 18:33:22 1996, tiggr@cobra.es.ele.tue.nl] When defining a
    class which does not inherit from an other class, have the class and the
    instance both inherit the `instance (All)'.

  4 [Wed Jun 12 18:24:57 1996, tiggr@cobra.es.ele.tue.nl] When messaging
    an inherited class variable which unexpectedly turns out to be nil,
    suspect the absence of `static' in its declaration.

  5 [Thu May 1 17:27:32 1997, tiggr@akebono.ics.ele.tue.nl] When while
    decoding the decoder raises a condition about a mismatching
    nextPrimary, suspect incorrect arguments to the hasBeenCodedFor
    method.

  6 [Tue Aug 26 11:22:49 1997, tiggr@natlab.research.philips.com] When the
    compiler moans about `xxx never responds to a method yyy', but you
    clearly see one declared and applicable, suspect the protection of the
    method to be more restrictive then you'd like.
