-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|727|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-

#
Monty Python Comments
: On a method called makeSnafucated insert only the Javadoc /* make snafucated */. Never define what snafucated means anywhere. Only a fool does not already know, with complete certainty, what snafucated means. For classic examples of this technique, consult the Sun AWT Javadoc.

Code Names Must Not Match Screen Names
: Choose your variable names to have absolutely no relation to the labels used when such variables are displayed on the screen, e. g. on the screen label the field "Postal Code" but in the code call the associated variable "zip".

Red Herrings
Pepper your code with variables that are never used and methods that are never called. This is most easily done by failing to remove code that is no longer used. You can save the code on grounds someday it may need to be revived. You get bonus points if these drone variables and methods have names similar to actual worker ones. The maintenance programmer will inevitably confuse the two. Changes made to drone code will happily compile, but have no effect.

#
Ensuring It Only Works In Debug Mode
: If you’ve defined TESTING as 1
#define TESTING 1
this gives you the wonderful opportunity to have separate code sections, such as
#if TESTING==1 #endif
which can contain such indispensable tidbits as
x = rt_val;
so that if anyone resets TESTING to 0, the program won’t work. And with the tiniest bit of imaginative work, it will not only befuddle the logic, but confound the compiler as well.