Ambiguity is the mother of confusion.The greatest skill comes in writing unmaintainable code that even you can’t figure out a short time after you write it. The key is ambiguity.
~ Roedy (born:1948-02-04 age:69)
Use the fuzziest, vaguest most general terminology you can come up with, especially for variable names. handle is a great example — a handle to what? processData is a great method name. Was there ever a method written that could not be so described? It cleverly hides any clue to what it does behind a cloud of ambiguity.
So, for example, when you mention the size of a display, make sure you make it abundantly unclear whether you mean to include the margins and/or the menu bar in the size. Mix both definitions in the same program using the same term for both.
If your boss insists you use the unambiguous terms payload size for the display without the margins and Applet size for the total display, subvert him by using just the word size, or use the wrong term occasionally.
Make sure, for example, the reader can’t tell whether a variable measures height of a display in lines of text or in pixels or some other unit of measure. Further, you want to seduce the reader into a false sense of security that he does understand. For example, use a variable called lines to measure the height of a text display in pixels.
When dealing with HTML (Hypertext Markup Language) text, make sure the reader can’t tell from the variable name, or the declaration comments if you are dealing with plain ASCII (American Standard Code for Information Interchange) text, high ASCII characters, embedded entities e.g. & or embedded tags e.g. <td>. Juggling all four sorts of beast without any convention for distinguishing them will make any head spin.
The Java version 1.4 Collections are a great place for introducing ambiguity. Every Collection is just a bunch of non-descript Objects. Who can tell without a close look what sort of Object is in each Collection? Never use Java version 1.5 generic types because they give away far too many clues. You can make the code even vaguer by using only interface references e.g. Map m and by reusing variables for quite different sorts of Collection.
The thing a maintenance programmer needs most is a bird’s eye picture of how it all works, a precis of the responsibilities of the various classes. There are so many ways it could work, you must not give away any hints. Make him sweat. Force him to read the details of every last line of code to put together that big picture.
The maintenance programmer is always looking for a shortcut — something he can safely ignore. Use ambiguity to give him a false sense of security.
This page is posted
Optional Replicator mirror
Your face IP:[126.96.36.199]
You are visitor number|