Friday, May 11, 2012

How to Write Unmaintainable Code

Given that there's a somewhat geeky discussion going on here I think I should add a dated but still truly excellent item. This is the sort of thing that makes me proud to be a Canadian.

"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 adsf 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 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.


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.
I'm positive I've linked it before. I like sending it to our IT people, which is probably why I've been testing one thing across a span of years.


ifthethunderdontgetya™³²®© said...

You're just begging me to put up one of my Apple IIe programs from the 80s as a blog post, aren't you.

I had 64k to work with, so even the line numbers used up memory.

I put as many statements on a line as I could. It looks like page after page of spaghetti BASIC, with no comments whatsoever.

And every cheap trick I could think of to make it the program shorter.

In fact, spaghetti BASIC doesn't do it justice, it was lasagna BASIC.

Substance McGravitas said...

Thundra, that's what CODE tags are FOR.

mikey said...


My expertise has long been figuring out how to get the development team to prioritize MY feature requests.

Once you can influence the developers, usually done with obscure european beer, artisan pizza and warm pastries and fried-dough products, you have effective control over the point-release road map and can make immense sums of money pre-selling upcoming features...

M. Bouffant said...

makes me proud to be a Canadian

Criminently, w/ y'all living in the upper bunk over the Great Satan the contrast alone should make you proud.

Smut Clyde said...

My code is always *self-documenting*, sir.