RULES FOR SOFTWARE DEVELOPERS

  1. mount: wrong fs type, bad option, bad superblock on //fileserver/foo, missing codepage or other error
  2. Never tell name or location of the file you couldn't open, or what access rights you're expecting
  3. Make sure an error message does not mention a possible cause or solution
  4. Ideally produce no error message at all
  5. When installing or updating a file, do not tell name or location, "installed" or "updated" is enough info
  6. Never check if called variables are actually set
  7. Never validate input; you can always trust a user to pass the correct option, feel free to explode if user passes unexpected parameters.
  8. Do not document
  9. Make sure "progname -h" crashes or at least prints "ERROR"
  10. Having a design is against the law
  11. If you output an error message, make sure to use a text that will produce at least 1.000.000 google hits
  12. Do not check preconditions, just lemming of the cliff and throw a useless error or dump a core
  13. Never use or check return values, that makes it too easy to determine where something went wrong
  14. Use bugzilla or broken mailinglist managers to effectively discourage users from reporting issues
  15. There shall be only one error value, and that value shall be -1.
  16. Magic numbers give your code amazing powers
  17. Always blame the user, he should have known better
  18. Never check for an error condition you don't know how to handle

Some fine examples

Note to the google victims hoping to find answers here: you will find thousands more having the same problems with bad software.