Caerdroia: Writing Unmaintainable Code

« 1LT Brian Chontosh | Main | The Federal Catechism »

November 21, 2005

Writing Unmaintainable Code

This is a brilliant discussion of how to code badly. Sadly, a few of my favorite examples have been left out. For example:

In the interest of efficiency, unroll subroutines and methods. Not only does this avoid the overhead of a method call or a JMP instruction, it also allows you to write, for example, your logging code with subtle differences based on where it is called. Make use of the latter property.
Object orientation is so confusing. Use large objects filled with procedural code — preferably code related to several different subproblems — so that you can instantiate the minimum number of objects. However, every single utility method should have its own class, as an efficiency. You don't need logging all the time, for example, but you always want to be able to get your hands on an employee, and if you need an employee you will probably also need to know about the building the employee works in. This is particularly useful when someone is trying to reuse your code without truly understanding it.
If you program in an object oriented language, and store your data in a SQL database, you can arrange things so that you can create objects like Employees — iterate the structure to find the one you need, and be sure to maintain the array reference to which employee that might be — rather than having an Employee object with the one employee you want. Clever use of this technique can make it impossible to get one row of data, or even all data related to one particular entry, at any one time.
Use design patterns, but not for their designed purpose. Create a data access object that contains all of the SQL queries you might need, but open and close the database in your main logic, and be sure to have a separate data access object, complete with application logic, for LDAP queries. If the maintenance programmer doesn't understand how the data is stored, how can he use it properly?
Lie to introspection routines.
Document a method as follows:
// MUST return a FOO, or misc. calculations of financial returns will be subtly wrong
Then return anything other than FOO. Make the maintenance programmer figure out if its a bug or a bad comment. As a bonus, a multi-billion dollar bank might lose confidence in years worth of calculations, requiring much manual audit work to determine whether or not the calculations are correct. Be sure not to mention, anywhere, which calculations might be subtly wrong.
Create two methods that do the same thing, in different ways. The arguments should be in different orders, and the names entirely dissimilar. Use the methods interchangeably.
Be stylistically inconsistent about blocks. Use all of:
```
abc {

}
```
and
```
abc
{
}
```
and
```
abc
    {
    }
```
Feel free to mix and match.
He mentions using tabs instead of spaces, but neglects the joy of having tabs used in some cases, and spaces used in others. This is particularly fun with odd tab sizes, like '3'.

Posted by jeff at November 21, 2005 4:30 PM

Trackback Pings

TrackBack URL for this entry:
http://www.caerdroia.org/MT/mt-tb.cgi/643


	A strange loop.