24 May 2007, 21:13 in Programming
How to write unmaintainable code
Brian sent me a link to an article How To Write Unmaintainable Code written by Roedy Green. As well as being funny, it’s a very good guide of what NOT to do when you’re programming.
A few excerpts that I particularly like include the following:
Thesaurus Surrogatisation
To break the boredom, use a thesaurus to look up as much alternate vocabulary as possible to refer to the same action, e.g. display, show, present. Vaguely hint there is some subtle difference, where none exists. However, if there are two similar functions that have a crucial difference, always use the same word in describing both functions (e.g. print to mean “write to a file”, “put ink on paper” and “display on the screen”). Under no circumstances, succumb to demands to write a glossary with the special purpose project vocabulary unambiguously defined. Doing so would be an unprofessional breach of the structured design principle of information hiding.
Misleading names
Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database.
Document How Not Why
Document only the details of what a program does, not what it is attempting to accomplish. That way, if there is a bug, the fixer will have no clue what the code should be doing.
Be polite, Never Assert
Avoid the assert() mechanism, because it could turn a three-day debug fest into a ten minute one.
When To Use Exceptions
Use exceptions for non-exceptional conditions. Routinely terminate loops with an ArrayIndexOutOfBoundsException. Pass return standard results from a method in an exception.
I can definitely relate to many of these.
Next article: Some notes on standup grappling from John Will seminar
Previous article: John Will seminar (May 2007)