Top Ten Signs that you are "Webbed Out"

Top Ten Signs that you are "Webbed Out"

10. Your opening line is, "So what's your home page address?"

9. Your best friend is someone you've never met.

8. You see a beautiful sunset, and you half expect to see "Enhanced for Netscape 3.0" on one of the clouds.

7. You are overcome with disbelief, anger and finally depressed when you encounter a Web page with no links.

6. You feel driven to consult the "Cool Page of the Day" on your wedding day.

5. You are diving on a dark and rainy night when you hydroplane on puddle, sending your car careening toward the flimsy guard rail that separates you from the precipice of a rocky cliff and certain death. You look for the "Back" button.

4. You visit "The Really Big Button that Doesn't Do Anything" again and again and again.

3. Your dog has his own Web page

2. So does your hamster.

.... And the No. 1 sign that you have overdosed on the WWW:

When you read a magazine, you have an irresistible urge to click on the underlined passages

What difference between physicist and programmer ?

Answer: Physicist thinks that 1 kilobyte = 1000 bytes, and programmer thinks that 1 kilometer = 1024 meters.

It seems the US Federal Aviation Administration (FAA) has a unique device for testing the strength of windshields on airplanes. The device is a gun that launches a dead chicken at a plane's windshield at approximately the speed the plane flies.

The theory is that if the windshield doesn't crack from the carcass impact, it'll survive a real collision with a bird during flight. It seems the British were very interested in this and wanted to test a windshield on a brand new, speedy locomotive they're developing.

They borrowed the FAA's chicken launcher, loaded the chicken and fired. The ballistic chicken shattered the windshield, went through the engineer's chair, broke an instrument panel and embedded itself in the back wall of the engine cab. The British were stunned and asked the FAA to recheck the test to see if everything was done correctly.

The FAA reviewed the test thoroughly and had one recommendation: "Use a thawed chicken."

A Mathematician, a Biologist and a Physicist are sitting in a street cafe
watching people going in and coming out of the house on the other side of
the street. First they see two people going into the house. Time passes.
After a while they notice three persons coming out of the house.
The Physicist: "The measurement wasn't accurate.".
The Biologists conclusion: "They have reproduced".
The Mathematician: "If now exactly 1 person enters the house then it will
be empty again."

Java Goes Open Source

Looks like the great Java king is disclosing it's crop source.

http://www.sun.com/2006-1113/feature/index.jsp

Writing Unmaintainable Code

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

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 thescope 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 use his language, tell him you can organise your thoughts better in your own language, or, if that does not work, allege linguistic discrimination and threaten to sue your employers for a vast sum.

Extended ASCII

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.

Names From Other Languages

Use foreign language dictionaries as a source for variable names. For example, use the German punkt for point. Maintenance coders, without your firm grasp of German, will enjoy the multicultural experience of deciphering the meaning.

Names From Mathematics

Choose variable names that masquerade as mathematical operators, e.g.:
openParen = (slash + asterix) / equals;

Bedazzling Names

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.

Rename and Reuse

This trick works especially well in Ada, a language immune to many of the standard obfuscation techniques. The people who originally named all the objects and packages you use were morons. Rather than try to convince them to change, just use renames and subtypes to rename everything to names of your own devising. Make sure to leave a few references to the old names in, as a trap for the unwary.

When To Use i

Never use i for the innermost loop variable. Use anything but. Use i liberally for any other purpose especially for non-int variables. Similarly use n as a loop index.

Conventions Schmentions

Ignore the Sun Java Coding Conventions, after all, Sun does. Fortunately, the compiler won't tattle when you violate them. The goal is to come up with names that differ subtlely only in case. If you are forced to use the capitalisation conventions, you can still subvert wherever the choice is ambigous, e.g. use bothinputFilename and inputfileName. Invent your own hopelessly complex naming conventions, then berate everyone else for not following them.

Lower Case l Looks a Lot Like the Digit 1

Use lower case l to indicate long constants. e.g. 10l is more likely to be mistaken for 101 that 10L is. Ban any fonts thatclearly disambiguate uvw wW gq9 2z 5s il17|!j oO08 `'" ;,. m nn rn {[()]}. Be creative.

Reuse of Global Names as Private

Declare a global array in module A, and a private one of the same name in the header file for 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.

Recycling Revisited

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.

Recycle Your Variables

Wherever scope rules permit, reuse existing unrelated variable names. Similarly, use the same temporary variable for two unrelated purposes (purporting to save stack slots). For a fiendish variant, morph the variable, for example, assign a value to a variable at the top of a very long method, and then somewhere in the middle, change the meaning of the variable in a subtle way, such as converting it from a 0-based coordinate to a 1-based coordinate. Be certain not to document this change in meaning.

Cd wrttn wtht vwls s mch trsr

When using abbreviations inside variable or method names, break the boredom with several variants for the same word, and even spell it out longhand once in while. This helps defeat those lazy bums who use text search to understand only some aspect of your program. Consider variant spellings as a variant on the ploy, e.g. mixing International colour, with American color and dude-speak kulerz. If you spell out names in full, there is only one possible way to spell each name. These are too easy for the maintenance programmer to remember. Because there are so many different ways to abbreviate a word, with abbreviations, you can have several different variables that all have the same apparent purpose. As an added bonus, the maintenance programmer might not even notice they are separate variables.

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

m_

a naming convention from the world of C++ is the use of "m_" in front of members. This is supposed to help you tell them apart from methods, so long as you forget that "method" also starts with the letter "m".

o_apple obj_apple

Use an "o" or "obj" prefix for each instance of the class to show that you're thinking of the big, polymorphic picture.

Hungarian Notation

Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack. The following tips will help you corrupt the original intent of Hungarian Notation:
Insist on using "c" for const in C++ and other languages that directly enforce the const-ness of a variable.

Seek out and use Hungarian warts that have meaning in languages other than your current language. For example insist on the PowerBuilder "l_" and "a_ " {local and argument} scoping prefixes and always use the VB-esque style of having a Hungarian wart for every control type when coding to C++. Try to stay ignorant of the fact that megs of plainly visible MFC source code does not use Hungarian warts for control types.

Always violate the Hungarian principle that the most commonly used variables should carry the least extra information around with them. Achieve this end through the techniques outlined above and by insisting that each class type have a custom wart prefix. Never allow anyone to remind you that no wart tells you that something is a class. The importance of this rule cannot be overstated if you fail to adhere to its principles the source code may become flooded with shorter variable names that have a higher vowel/consonant ratio. In the worst case scenario this can lead to a full collapse of obfuscation and the spontaneous reappearance of English Notation in code!

Flagrantly violate the Hungarian-esque concept that function parameters and other high visibility symbols must be given meaningful names, but that Hungarian type warts all by themselves make excellent temporary variable names.

Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table's primary key. When properly combined with the principle that "all variables should be public" this technique has the power to render thousands of lines of source code obsolete instantly!

Use to your advantage the principle that the human brain can only hold 7 pieces of information concurrently. For example code written to the above standard has the following properties:

• a single assignment statement carries 14 pieces of type and name information.
• a single function call that passes three parameters and assigns a result carries 29 pieces of type and name information.
• Seek to improve this excellent, but far too concise, standard. Impress management and coworkers by recommending a 5 letter day of the week prefix to help isolate code written on 'Monam' and 'FriPM'.
• It is easy to overwhelm the short term memory with even a moderately complex nesting structure, especially when the maintenance programmer can't see the start and end of each block on screen simultaneously.

Hungarian Notation Revisited

One followon trick in the Hungarian notation is "change the type of a variable but leave the variable name unchanged". This is almost invariably done in windows apps with the migration from Win16 :- WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam) to Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) where the w values hint that they are words, but they really refer to longs. The real value of this approach comes clear with the Win64 migration, when the parameters will be 64 bits wide, but the old "w" and "l" prefixes will remain forever.

Reduce, Reuse, Recycle

If you have to define a structure to hold data for callbacks, always call the structure PRIVDATA. Every module can define it's own PRIVDATA. In VC++, this has the advantage of confusing the debugger so that if you have a PRIVDATA variable and try to expand it in the watch window, it doesn't know which PRIVDATA you mean, so it just picks one.

Obscure film references

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.

read more

Writing Unmaintainable Code

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

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 thescope 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 use his language, tell him you can organise your thoughts better in your own language, or, if that does not work, allege linguistic discrimination and threaten to sue your employers for a vast sum.

Extended ASCII

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.

Names From Other Languages

Use foreign language dictionaries as a source for variable names. For example, use the German punkt for point. Maintenance coders, without your firm grasp of German, will enjoy the multicultural experience of deciphering the meaning.

Names From Mathematics

Choose variable names that masquerade as mathematical operators, e.g.:
openParen = (slash + asterix) / equals;

Bedazzling Names

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.

Rename and Reuse

This trick works especially well in Ada, a language immune to many of the standard obfuscation techniques. The people who originally named all the objects and packages you use were morons. Rather than try to convince them to change, just use renames and subtypes to rename everything to names of your own devising. Make sure to leave a few references to the old names in, as a trap for the unwary.

When To Use i

Never use i for the innermost loop variable. Use anything but. Use i liberally for any other purpose especially for non-int variables. Similarly use n as a loop index.

Conventions Schmentions

Ignore the Sun Java Coding Conventions, after all, Sun does. Fortunately, the compiler won't tattle when you violate them. The goal is to come up with names that differ subtlely only in case. If you are forced to use the capitalisation conventions, you can still subvert wherever the choice is ambigous, e.g. use bothinputFilename and inputfileName. Invent your own hopelessly complex naming conventions, then berate everyone else for not following them.

Lower Case l Looks a Lot Like the Digit 1

Use lower case l to indicate long constants. e.g. 10l is more likely to be mistaken for 101 that 10L is. Ban any fonts thatclearly disambiguate uvw wW gq9 2z 5s il17|!j oO08 `'" ;,. m nn rn {[()]}. Be creative.

Reuse of Global Names as Private

Declare a global array in module A, and a private one of the same name in the header file for 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.

Recycling Revisited

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.

Recycle Your Variables

Wherever scope rules permit, reuse existing unrelated variable names. Similarly, use the same temporary variable for two unrelated purposes (purporting to save stack slots). For a fiendish variant, morph the variable, for example, assign a value to a variable at the top of a very long method, and then somewhere in the middle, change the meaning of the variable in a subtle way, such as converting it from a 0-based coordinate to a 1-based coordinate. Be certain not to document this change in meaning.

Cd wrttn wtht vwls s mch trsr

When using abbreviations inside variable or method names, break the boredom with several variants for the same word, and even spell it out longhand once in while. This helps defeat those lazy bums who use text search to understand only some aspect of your program. Consider variant spellings as a variant on the ploy, e.g. mixing International colour, with American color and dude-speak kulerz. If you spell out names in full, there is only one possible way to spell each name. These are too easy for the maintenance programmer to remember. Because there are so many different ways to abbreviate a word, with abbreviations, you can have several different variables that all have the same apparent purpose. As an added bonus, the maintenance programmer might not even notice they are separate variables.

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

m_

a naming convention from the world of C++ is the use of "m_" in front of members. This is supposed to help you tell them apart from methods, so long as you forget that "method" also starts with the letter "m".

o_apple obj_apple

Use an "o" or "obj" prefix for each instance of the class to show that you're thinking of the big, polymorphic picture.

Hungarian Notation

Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack. The following tips will help you corrupt the original intent of Hungarian Notation:
Insist on using "c" for const in C++ and other languages that directly enforce the const-ness of a variable.

Seek out and use Hungarian warts that have meaning in languages other than your current language. For example insist on the PowerBuilder "l_" and "a_ " {local and argument} scoping prefixes and always use the VB-esque style of having a Hungarian wart for every control type when coding to C++. Try to stay ignorant of the fact that megs of plainly visible MFC source code does not use Hungarian warts for control types.

Always violate the Hungarian principle that the most commonly used variables should carry the least extra information around with them. Achieve this end through the techniques outlined above and by insisting that each class type have a custom wart prefix. Never allow anyone to remind you that no wart tells you that something is a class. The importance of this rule cannot be overstated if you fail to adhere to its principles the source code may become flooded with shorter variable names that have a higher vowel/consonant ratio. In the worst case scenario this can lead to a full collapse of obfuscation and the spontaneous reappearance of English Notation in code!

Flagrantly violate the Hungarian-esque concept that function parameters and other high visibility symbols must be given meaningful names, but that Hungarian type warts all by themselves make excellent temporary variable names.

Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table's primary key. When properly combined with the principle that "all variables should be public" this technique has the power to render thousands of lines of source code obsolete instantly!

Use to your advantage the principle that the human brain can only hold 7 pieces of information concurrently. For example code written to the above standard has the following properties:

• a single assignment statement carries 14 pieces of type and name information.
• a single function call that passes three parameters and assigns a result carries 29 pieces of type and name information.
• Seek to improve this excellent, but far too concise, standard. Impress management and coworkers by recommending a 5 letter day of the week prefix to help isolate code written on 'Monam' and 'FriPM'.
• It is easy to overwhelm the short term memory with even a moderately complex nesting structure, especially when the maintenance programmer can't see the start and end of each block on screen simultaneously.

Hungarian Notation Revisited

One followon trick in the Hungarian notation is "change the type of a variable but leave the variable name unchanged". This is almost invariably done in windows apps with the migration from Win16 :- WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam) to Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) where the w values hint that they are words, but they really refer to longs. The real value of this approach comes clear with the Win64 migration, when the parameters will be 64 bits wide, but the old "w" and "l" prefixes will remain forever.

Reduce, Reuse, Recycle

If you have to define a structure to hold data for callbacks, always call the structure PRIVDATA. Every module can define it's own PRIVDATA. In VC++, this has the advantage of confusing the debugger so that if you have a PRIVDATA variable and try to expand it in the watch window, it doesn't know which PRIVDATA you mean, so it just picks one.

Obscure film references

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.

read more

Template Support Form

SYSTEM PROBLEM REPORT
This is a form to make the reporting of problems consistent and
allow records of problems to be kept.

1. Your Name: __________________________
2. Your Login Name: ____________________
2. Your Password: ______________________
3. The date? __/__/__
4. The date the problem first occurred if different? __/__/__
5. Problem severity:
Minor ___ Minor ___ Minor ___ Minor ___
6. Which machine?
7. What appears to be at fault?
Communications ___ Disk ___ Base Unit ___
Network ___ Keyboard ___ Screen ___
Mouse ___ Everything ___ Don't Know ___
7.1 Is it plugged in? Yes___ No ___
7.2 Is it switched on? Yes___ No ___
7.3 Has it been stolen? Yes___ No ___
7.4 Have you tried to fix it yourself? Yes___ No ___
7.4.1 Have you made it worse? Yes___ No ___
7.5 Have you read the manual? Yes___ No ___
7.5.1 Are you sure you've read the manual? Yes___ No ___
7.5.2 Are you absolutely certain you've read the manual?
Yes___ No ___
7.6 Did you understand it? Yes___ No ___
7.6.1 If 'Yes", then why can't you fix it yourself?
______________________________________________________
7.7 Is the equipment unexpectedly noisy? Yes___ No ___
7.7.1 If 'Yes", what sort of noise?
Grinding __ Rattling __ Whirring __ High Pitched Whine __
Sound of disk head scouring disk ___
Strange, out of tune whistling or humming ___
7.8 Is there a smell of burning? Yes___ No ___
7.8.1 If "Yes", is the equipment on fire? Yes___ No ___
7.9 Is the fault repeatable? Yes___ No ___
7.10 What were you doing (with the equipment) at the time the
fault occurred?
______________________________________________________
______________________________________________________
7.10.1 If 'Nothing', explain why you were logged in.
______________________________________________________
7.12 Do you have any independent witnesses of the problem?
Yes___ No ___
7.13 Describe the problem
______________________________________________________
7.14 Now, describe the problem accurately
______________________________________________________
7.15 Speculate wildly about the cause of the problem
______________________________________________________
______________________________________________________
7.16 Can't you do something else, rather than bothering me?
Yes___ No __

Lightbulb Jokes - Computers

How many Pentium designers does it take to screw in a light bulb?

1.99904274017, but that's close enough for non-technical people.

How many IBM CPU's does it take to turn on a light bulb?

33 - 1 to process the instruction and 32 to process the interrupt.

How many electrical engineers does it take to change a light bulb?

We don't know yet. They're still waiting on a part.

How many hardware engineers does it take to change a light bulb?

None. "We'll fix it in software."

How many software engineers does it take to change a light bulb?

1. None. "We'll document it in the manual."
2. None. It's a hardware problem.
3. One, but if he changes it, the whole building will probably fall down.
4. Two. One always leaves in the middle of the project.
5. Four. One to design the change, one to implement it, one to document it, and one to maintain it afterwards.
6. Four, plus one senior analyst to manage the project, one technical writer to correct the spelling and grammar of the one who documented it, one light bulb librarian, a sales-force of at least five to drum up enough users who want to turn the light on, 274 users to burn out the new bulb, at which point we go to tender for another light bulb change,...
7. Five. Two to write the specification program, one to screw it in, and two to explain why the project was late.
8. Wait! Maybe the bulb isn't broken. Let's try it again.
9. It's hard to say. Each time we separate the bulb into its modules to do unit testing, it stops working.
10. The change is 90% complete.
11. We looked at the light fixture and decided there's no point trying to maintain it. We're going to rewrite it from scratch. Could you wait two months?
12. Only one, but she's not available. She's the only programmer we have who can get the software ready to ship to customers, and that's higher priority, you know.
13. Of course, as everyone knows, just five years ago all it took was a bunch of kids in a garage in Palo Alto to change a light bulb.

How many real programmers does it take to change a light bulb?

None. Real programmers prefer LEDs.

How many C programmers does it take to change a light bulb?

None, they forgot to declare it first

How long does it take a C programmer to screw in a light bulb?

24 hours - 3 minutes to put in the bulb, the rest of the time to compile all the libraries.

How many C++ programmers does it take to change a light bulb?

You're still thinking procedurally. A properly designed light bulb object would inherit a change method from a generic light bulb class, so all you'd have to do is send a light bulb change message.

How many people does it take to change an object-oriented light bulb?

Change it? Aw shucks, I was going to reuse it.

How many FORTRAN programs does it take to change a light bulb?

1.00000000001

How many BASIC programmers does it take to screw in a light bulb?

10 push bulb upwards:twist bulb clockwise 20 goto 10

How many games machine programmers does it take to screw in a light-bulb?

One, but he needs the seal of approval from Nintendo before he can put his light-bulb in their socket.

How many Prolog programmers does it take to change a light bulb?

False.

How many Lisp programmers does it take to change a light bulb?

1. Hmmm, I'm not sure, better find out....
   Hmmm, I'm not sure, better find out....
   Notes: LISP is a recursive programming language. One problem LISP programmers have to contend with is infinite recursion. (cf computer dictionary entry: recursion - see recursion) These lisp heads are usually research AI types and their standard answer is as in the punchline. It could be improved:
2. (((H)mmm,) (I'm ((not) sure, better))) (find (out))...

How many data base people does it take to change a light bulb?

Three: One to write the light bulb removal program, one to write the light bulb insertion program, and one to act as a light bulb administrator to make sure nobody else tries to change the light bulb at the same time.

How many tech writers does it take to change a light bulb?

None. "The user can work it out."

How many developers does it take to change a light bulb?

The light bulb works fine on the system in my office . . .

How many field service engineers does it take to replace a dead light bulb?

1. Who can tell. FSE's are always in the dark.
2. Two. One to hold the bulb and one to pound it in (etc)
3. Well, the diagnostics all check out fine, so it's a software problem.

How long will it take?

That's indeterminate. It depends on how many dead bulbs they've brought with them.

What if you have two dead bulbs?

They replace your fuse box.

How many system administrators does it take to change a light bulb?

None, they just keep everyone out of the room.

How many IBM engineers does it take to screw in a light bulb?

None. They just let Marketing explain that "Dead Bulb" is a feature.

How many IBM PC owners does it take to screw in a light bulb?

1. Only one, but he'll have to go out and buy the light bulb adaptor card first, which is extra.
2. Two. One to do it, but one to check the new bulb for viruses first.

How many IBM tech writers does it take to screw in a light bulb?

1. 100. Ten to do it, and 90 to write document number GC7500439-0001, Multitasking Incandescent Source System Facility, of which 10% of the pages state only "This page intentionally left blank", and 20% of the definitions are of the form "A ...... consists of sequences of non-blank characters separated by blanks".
2. Just one, provided there's an engineer around to explain how to do it.

How many Microsoft engineers does it take to screw in a light bulb?

None. They just define darkness as an industry standard.

How many Microsoft employees does it take to change a light bulb?

1. One - but Bill Gates must inspect every single bulb and socket before the operation is started.
2. Eight: one to work the bulb and seven to make sure Microsoft gets $2 for every light bulb ever changed anywhere in the world.

How many MS tech supports does it take to change a light bulb?

"The light bulb doesn't work? You must be using a non-standard socket."

How many operating systems are required to screw in a light bulb?

Just one-Microsoft is making a special version of Windows for it.

How many Windows programmers does it take to change a light bulb?

472. One to write WinGetLight BulbHandle, one to write WinQueryStatusLight Bulb, one to write WinGetLightSwitchHandle...

How many Windows users does it take to change a light bulb?

One, but she/he'll swear up and down that it was JUST as easy for him as it would be for a Macintosh user.

How many Macintosh engineers does it take to screw in a light bulb?

None - it has to be done by a local authorized dealer.

How many Apple employees does it take to screw in a light bulb?

Seven. One to screw it in and six to design the tee-shirts.

How many Apple programmers does it take to change a light bulb?

Only one, but why bother? Your light socket will just be obsolete in six months anyway.

How many Mac owners does it take to screw in a light bulb?

1. None - there's no documentation available, so you have to wait until a third-party supplier comes out with a solution.
2. Just one, but the new light bulbs aren't compatible with the old sockets, so he has to buy a complete upgrade or a new light.
3. Two: One to ask the socket to eject the old bulb, and one to insert the new one.
4. Three: One to change the bulb, one to copyright the method for changing the bulb, and one to call in the lawyers on anyone who infringes on the "look and feel" of the bulb changing method.
5. Mac users don't screw, they just click the genital icon.

How many Apple and IBM nuts does it take to change a light bulb?

An infinite number: nothing useful gets done while they're arguing. Finally a disgusted generic computer user (who will use any type that is in front of him) gets up and changes the bulb, elbowing the participants aside. The size of the crowd arguing seems to be a function of time, although whether or not the function is exponential is not known.

How many Unix hacks does it take to change a light bulb?

1. As many as you want; they're all virtual, anyway.
2. One, but first he has to determine the correct path.

How many Unix programmers does it take to change a light bulb?

Only one, but if you forget to tell him "2>" he'll mash both the live and dead bulbs into the same socket at once.

How many Unix Support staff does it take to screw in a light bulb?

Read the man page!

How many Unix system vendors does it take to change a light bulb?

None. All of the light bulbs you have are 'standard variants' and as such won't fit your particular implementation of the socket. (However you do have the source code for your socket, so .....)

How many VMS heads does it take to change a light bulb?

All of them, and they will all scream at you in unison and tell you that the only light bulb you can use is a 100-watt soft white but you can use any 100-watt soft white as long as it's manufactured by DEC.

Tech Support Pricing

An excellent list of tech support pricing:

http://www.contrib.andrew.cmu.edu/~moose/sysadmin/pricelist.html

Top 17 Programmer's Terminologies

Top 17 Programmer's Terminologies

1. A NUMBER OF DIFFERENT APPROACHES ARE BEING TRIED
- We are still pissing in the wind.

2. EXTENSIVE REPORT IS BEING PREPARED ON A FRESH APPROACH TO
THE PROBLEM
- We just hired three kids fresh out of college.

3. CLOSE PROJECT COORDINATION
- We know who to blame.

4. MAJOR TECHNOLOGICAL BREAKTHROUGH
- It works OK, but looks very hi-tech.

5. CUSTOMER SATISFACTION IS DELIVERED ASSURED
- We are so far behind schedule the customer is happy to
get it delivered.

6. PRELIMINARY OPERATIONAL TESTS WERE INCONCLUSIVE
- The darn thing blew up when we threw the switch.

7. TEST RESULTS WERE EXTREMELY GRATIFYING
- We are so surprised that the stupid thing works.

8. THE ENTIRE CONCEPT WILL HAVE TO BE ABANDONED
- The only person who understood the thing quit.

9. IT IS IN THE PROCESS
- It is so wrapped up in red tape that the situation
is about hopeless.

10. WE WILL LOOK INTO IT
- Forget it! We have enough problems for now.

11. PLEASE NOTE AND INITIAL
- Let's spread the responsibility for the screw up.

12. GIVE US THE BENEFIT OF YOUR THINKING
- We'll listen to what you have to say as long as it
doesn't interfere with what we've already done.

13. GIVE US YOUR INTERPRETATION
- I can't wait to hear this bull!

14. SEE ME or LET'S DISCUSS
- Come into my office, I'm lonely.

15. ALL NEW
- Code not interchangeable with the previous design.

16. YEARS OF DEVELOPMENT
- It finally worked!

17. LOW MAINTENANCE
- Impossible to fix if broken.

 # All your space are belong to perl
$customer =~ s/ //g;

Funny Things Found in Source Code...

  // Since this file is loaded on every page, and since
 // I want the following function on every page, I'm going to
 // cheat and include it here even though it has nothing to
 // do with the other things in this file.
 // If you don't like it, bite me!