Difference between revisions of "Unmaintainable code"

From Wiki @ Karl Jones dot com
Jump to: navigation, search
(Dealing With Others)
(Roll Your Own)
Line 76: Line 76:
  
 
=== Roll Your Own ===  
 
=== Roll Your Own ===  
 +
 +
"You’ve always wanted to write system level code. Now is your chance. Ignore the standard libraries and write your own. It will look great on your resumé."
  
 
[http://mindprod.com/jgloss/unmainrollyourown.html Link]
 
[http://mindprod.com/jgloss/unmainrollyourown.html Link]

Revision as of 08:27, 18 August 2015

Unmaintainable code is an essay by Roedy Green about [[software development], software testing, code refactoring, and related topics.

It is a satire in the tradition of The Devil's Dictionary.

Many of the examples use Java, but the general principles apply to all programming languages.

See the official website for the complete essay.

Topics

General Principles

"You want to make it as hard as possible for [the maintenance programmer] 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. By every once in a while, by subtly violating convention, you force him to read every line of your code with a magnifying glass."

Link

Naming

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

Link

Camouflage

"Much of the skill in writing unmaintainable code is the art of camouflage, hiding things, or making things appear to be what they are not."

Link

Documentation

"Since the computer ignores comments and documentation, you can lie outrageously and do everything in your power to befuddle the poor maintenance programmer."

Link

Program Design

"The cardinal rule of writing unmaintainable code is to specify each fact in as many places as possible and in as many ways as possible."

Link

Coding Obfuscation

"Sedulously eschew obfuscatory hyperverbosity and prolixity." (Anon.)

Link

Ambiguity

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

Link

Testing

"Leaving bugs in your programs gives the maintenance programmer who comes along later something interesting to do. A well done bug should leave absolutely no clue as to when it was introduced or where. The laziest way to accomplish this is simply never to test your code."

Link

See also Software testing.

Choice of Language

"Computer languages are gradually evolving to become more fool proof. Using state of the art languages is unmanly. Insist on using the oldest language you can get away with ..."

Link

Dealing With Others

"Hell is other people." -- Jean-Paul Sartre

Link

Roll Your Own

"You’ve always wanted to write system level code. Now is your chance. Ignore the standard libraries and write your own. It will look great on your resumé."

Link

Tricks In Offbeat Languages

Link

Miscellaneous Techniques

Link

Philosophy

Link

The Shoemaker Has No Shoes

Link

Contributors

Link

Operation Termite

Link

Feedback

Link

See also

External links