unmaintainable-code

How To Write Unmaintainable Code Ensure a job for life ;-) Roedy Green Canadian Mind Products Reproduced with permission from the author, circa 2015 Introduction Never ascribe to malice, that which can be explained by incompetence. - Napoleon In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn't be able to maintain the code! You don't want to overdo this. Your code should not look hopelessly unmaintainable, just be that way. Otherwise it stands the risk of being rewritten or refactored. General Principles Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound. To foil the maintenance programmer, you have to understand how he thinks. He has your giant program. He has no time to read it all, much less understand it. He wants to rapidly find the place to make his change, make it and get out and have no unexpected side effects from the change. He views your code through a toilet paper tube. He can only see a tiny piece of your program at a time. You want to make sure he can never get at the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for him to safely ignore anything. Programmers are lulled into complacency by conventions. But every once in a while, by subtly violating convention, you force him to read every line of your code with a magnifying glass. You might get the idea that every language feature makes code unmaintainable -- not so, only if properly misused. Naming "When I use a word," Humpty Dumpty said, in a rather scornful tone, "it means just what I choose it to mean - neither more nor less." Lewis Carroll -- Through the Looking Glass, Chapter 6 Much of the skill in writing unmaintainable code is the art of naming variables and methods. They don't matter at all to the compiler. That gives you huge latitude to use them to befuddle the maintenance programmer. New Uses For Names For Baby Buy a copy of a baby naming book and you'll never be at a loss for variable names. Fred is a wonderful name, and easy to type. If you're looking for easy-to-type variable names, try asdf or aoeu if you type with a DSK keyboard. Single Letter Variable Names If you call your variables a, b, c, then it will be impossible to search for instances of them using a simple text editor. Further, nobody will be able to guess what they are for. If anyone even hints at breaking the tradition honoured since FØRTRAN of using i, j, and k for indexing variables, namely replacing them with ii, jj and kk, warn them about what the Spanish Inquisition did to heretics. Creative Miss-spelling If you must use descriptive variable and function names, misspell them. By misspelling in some function and variable names, and spelling it correctly in others (such as SetPintleOpening and SetPintalClosing) we effectively negate the use of grep or IDE search techniques. It works amazingly well. Add an international flavor by spelling tory or tori in different theatres/theaters. Be Abstract In naming functions and variables, make heavy use of abstract words like it, everything, data, handle, stuff, do, routine, perform and the digits e.g. routineX48, PerformDataFunction, DoIt, HandleStuff and do_args_method. A.C.R.O.N.Y.M.S. Use acronyms to keep the code terse. Real men never define acronyms; they understand them genetically. 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. Use Plural Forms From Other Languages A VMS script kept track of the "statii" returned from various "Vaxen". Esperanto , Klingon and Hobbitese qualify as languages for these purposes. For pseudo-Esperanto pluraloj, add oj. You will be doing your part toward world peace. CapiTaliSaTion Randomly capitalize the first letter of a syllable in the middle of a word. For example ComputeRasterHistoGram(). Reuse Names Wherever the rules of the language permit, give classes, constructors, methods, member variables, parameters and local variables the same names. For extra points, reuse local variable names inside {} blocks. The goal is to force the maintenance programmer to carefully examine the scope of every instance. In particular, in Java, make ordinary methods masquerade as constructors. Åccented Letters Use accented characters on variable names. E.g. typedef struct { int i; } ínt; where the second ínt's í is actually i-acute. With only a simple text editor, it's nearly impossible to distinguish the slant of the accent mark. Exploit Compiler Name Length Limits If the compiler will only distinguish the first, say, 8 characters of names, then vary the endings e.g. var_unit_update() in one case and var_unit_setup() in another. The compiler will treat both as var_unit. Underscore, a Friend Indeed Use _ and __ as identifiers. Mix Languages Randomly intersperse two languages (human or computer). If your boss insists you u