Difference between revisions of "Unmaintainable code"
Karl Jones (Talk | contribs) (→Choice of Language) |
Karl Jones (Talk | contribs) (→Dealing With Others) |
||
Line 70: | Line 70: | ||
=== Dealing With Others === | === Dealing With Others === | ||
+ | |||
+ | "Hell is other people." -- Jean-Paul Sartre | ||
+ | |||
[http://mindprod.com/jgloss/unmainotherpeople.html Link] | [http://mindprod.com/jgloss/unmainotherpeople.html Link] | ||
Revision as of 08:26, 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.
Contents
- 1 Topics
- 1.1 General Principles
- 1.2 Naming
- 1.3 Camouflage
- 1.4 Documentation
- 1.5 Program Design
- 1.6 Coding Obfuscation
- 1.7 Ambiguity
- 1.8 Testing
- 1.9 Choice of Language
- 1.10 Dealing With Others
- 1.11 Roll Your Own
- 1.12 Tricks In Offbeat Languages
- 1.13 Miscellaneous Techniques
- 1.14 Philosophy
- 1.15 The Shoemaker Has No Shoes
- 1.16 Contributors
- 1.17 Operation Termite
- 1.18 Feedback
- 2 See also
- 3 External links
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."
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."
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."
Documentation
"Since the computer ignores comments and documentation, you can lie outrageously and do everything in your power to befuddle the poor maintenance programmer."
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."
Coding Obfuscation
"Sedulously eschew obfuscatory hyperverbosity and prolixity." (Anon.)
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."
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."
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 ..."
Dealing With Others
"Hell is other people." -- Jean-Paul Sartre