Ignore the[Sun Java Coding Conventions](http://web.archive.org/web/20091003224540/http://java.sun.com/docs/codeconv/), after all, Sun does. Fortunately, the compiler won't tattle when you violate them. The goal is to come up with names that differsubtlely only in case. If you are forced to use the capitalisation conventions, you can still subvert wherever the choice isambigous, e.g. use*both*_input**F**ile**n**ame_ and_input**f**ile**N**ame_. Invent your own hopelessly complex naming conventions, then berate everyone else for not following them.

Ignore the[Sun Java Coding Conventions](http://web.archive.org/web/20091003224540/http://java.sun.com/docs/codeconv/), after all, Sun does. Fortunately, the compiler won't tattle when you violate them. The goal is to come up with names that differsubtly only in case. If you are forced to use the capitalisation conventions, you can still subvert wherever the choice isambiguous, e.g. use*both*_input**F**ile**n**ame_ and_input**f**ile**N**ame_. Invent your own hopelessly complex naming conventions, then berate everyone else for not following them.

Onefollowon 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:

Onefollow-on 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)

#define local_var xy_z // in file ..\codestd\inst.h

#### Compiler Directives

Compiler directives were designed with the express purpose of making the same code behave completely differently. Turn the booleanshort-circuiting directive on and off repeatedly andvigourously, as well as thelong strings directive.

Compiler directives were designed with the express purpose of making the same code behave completely differently. Turn the booleanshort-circuiting directive on and off repeatedly andvigorously, as well as thelong strings directive.

## Documentation

Pepper the code with comments like`/* add 1 to i */` however, never documentwooly stuff like the overall purpose of the package or method.

Pepper the code with comments like`/* add 1 to i */` however, never documentwoolly stuff like the overall purpose of the package or method.

Use both accessor methods and public variables. That way, you can change an object's variable without the overhead of calling the accessor, but still claim that the class is a "Java Bean". This has the additional advantage of frustrating themaintenence programmer who adds a logging function to try to figure out who is changing the value.

Use both accessor methods and public variables. That way, you can change an object's variable without the overhead of calling the accessor, but still claim that the class is a "Java Bean". This has the additional advantage of frustrating themaintenance programmer who adds a logging function to try to figure out who is changing the value.

Make as many of your variables as possible static. If_you_ don't need more than one instance of the class in this program, no one else ever will either. Again, if other coders in the project complain, tell them about the execution speed improvement you're getting.

Take advantage of Cargill's quandary (I think this was his) "any design problem can be solved by adding an additional level of indirection, except for too many levels of indirection." Decompose OO programs until it becomes nearly impossible to find a method which actually updates program state. Better yet, arrange all such occurrences to be activated as callbacks from by traversing pointer forests which are known to contain every function pointer used within the entire system. Arrange for the forest traversals to be activated as side-effects from releasing reference counted objects previously created via deep copies which aren't really all that deep.

If you have an array with 100 elements in it, hard code the literal 100 in as many places in the program as possible. Never use a static final named constant for the 100, or refer to it as`myArray.length`. To make changing this constant even more difficult, use the literal 50 instead of 100/2, or 99 instead of 100-1. You canfuther disguise the 100 by checking for`a == 101` instead of`a > 100`, or`a > 99` instead of`a >= 100`.

If you have an array with 100 elements in it, hard code the literal 100 in as many places in the program as possible. Never use a static final named constant for the 100, or refer to it as`myArray.length`. To make changing this constant even more difficult, use the literal 50 instead of 100/2, or 99 instead of 100-1. You canfurther disguise the 100 by checking for`a == 101` instead of`a > 100`, or`a > 99` instead of`a >= 100`.

Consider things like page sizes, where the lines consisting of x header, y body, and z footer lines, you can apply the obfuscations independently to each of these and to their partial or total sums.

These time-honoured techniques are especially effective in a program with two unrelated arrays that just accidentally happen to both have 100 elements. If the maintenance programmer has to change the length of one of them, he will have to decipher every use of the literal 100 in the program to determine which array it applies to. He is almost sure to make at least one error, hopefully one that won't show up for years later.

Have the makefile-generated-batch-file copy source files from multiple directories with undocumentedoverrwrite rules. This permits code branching without the need for any fancy source code control system, and stops your successors ever finding out which version of`DoUsefulWork()` is the one they should edit.

Have the makefile-generated-batch-file copy source files from multiple directories with undocumentedoverwrite rules. This permits code branching without the need for any fancy source code control system, and stops your successors ever finding out which version of`DoUsefulWork()` is the one they should edit.

The people who design languages are the people who write the compilers and system classes. Quite naturally they design to make their work easy and mathematically elegant. However, there are 10,000 maintenance programmers to every compiler writer. The grunt maintenance programmers have absolutely no say in the design of languages. Yet the total amount of code they write dwarfs the code in the compilers.

An example of the result of this sort of elitist thinking is the JDBC interface. It makes life easy for the JDBCimplementor, but a nightmare for the maintenance programmer. It is far**clumsier** than the FORTRAN interface that came out with SQL three decades ago.

An example of the result of this sort of elitist thinking is the JDBC interface. It makes life easy for the JDBCimplementer, but a nightmare for the maintenance programmer. It is far**clumsier** than the FORTRAN interface that came out with SQL three decades ago.

Maintenance programmers, if somebody ever consulted them, would demand ways to hide the housekeeping details so they could see the forest for the trees. They would demand all sorts of shortcuts so they would not have to type so much and so they could see more of the program at once on the screen. They would complain loudly about the myriad petty time-wasting tasks the compilers demand of them.