Interlude: How not to Write Code


In my Internet travels , I came across a marvelous essay written by Roedy Green, a Canadian software developer. After finding that developers paid no attention when he talked about writing maintainable code, he decided instead to write about developing unmaintainable code. In a detailed and very humorous article, he shows his readers how to write code that is so difficult to understand that nobody but the author has a chance of maintaining it, thus guaranteeing employment for life.

Although the essay specifically targets Java, many of its points transfer directly to VB .NET. So with Roedy's kind permission, here are some excerpts from his article that deal with variable naming and scoping. You can find the full text of the article at http://mindprod.com/unmain.html. It's well worth reading the whole essay if you want to understand and avoid many common maintenance problems.

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.

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.

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.

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

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.

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 .

Randomly capitalize the first letter of a syllable in the middle of a word. For example: ComputeRasterHistoGram() .

Extended ASCII characters are perfectly valid as variable names, including , , and ± characters. They are almost impossible to type without copying/ pasting in a simple text editor.

Choose variable names that masquerade as mathematical operators, e.g.:

 openParen = (slash + asterix) / equals 

Choose variable names with irrelevant emotional connotation, e.g.:

 marypoppins = (superman + starship) / god 

This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to think about.

Declare a global array in module A , and a private one of the same name in module B , so that it appears that it's the global array you are using in module B , but it isn't. Make no reference in the comments to this duplication.

Use scoping as confusingly as possible by recycling variable names in contradictory ways. For example, suppose you have global variables A and B , and functions foo and bar . If you know that variable A will be regularly passed to foo and B to bar , make sure to define the functions as function foo(B) and function bar(A) so that inside the functions A will always be referred to as B and vice versa. With more functions and globals , you can create vast confusing webs of mutually contradictory uses of the same names.

Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database.

Use constant names like LancelotsFavouriteColour instead of blue and assign it hex value of $0204FB. The color looks identical to pure blue on the screen, and a maintenance programmer would have to work out 0204FB (or use some graphic tool) to know what it looks like. Only someone intimately familiar with Monty Python and the Holy Grail would know that Lancelot's favorite color was blue. If a maintenance programmer can't quote entire Monty Python movies from memory, he or she has no business being a programmer.

Use very long variable names or class names that differ from each other by only one character, or only in upper/lowercase. An ideal variable name pair is swimmer and swimner . Exploit the failure of most fonts to clearly discriminate between ilI1 or oO08 with identifier pairs like parselnt and parseInt or D0Calc and DOCalc . l is an exceptionally fine choice for a variable name since it will, to the casual glance, masquerade as the constant 1 . In many fonts rn looks like an m . So how about a variable swirnrner ? Create variable names that differ from each other only in case e.g. HashTable and Hashtable . (Editorial note: This last trick can be done in C#, but not VB.)

"Although we have one variable named xy_z , there's certainly no reason not to have many other variables with similar names, such as xy_Z , xy__z , _xy_z , _xyz , XY_Z , xY_z , and Xy_z . Variables that resemble others except for capitalization and underlines have the advantage of confounding those who like remembering names by sound or letter-spelling, rather than by exact representations. (Editorial note: Once again, the capitalization trick can only be done with C#.)"




Comprehensive VB .NET Debugging
Comprehensive VB .NET Debugging
ISBN: 1590590503
EAN: 2147483647
Year: 2003
Pages: 160
Authors: Mark Pearce

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net