This -> writing unmaintainable code originally focused on Java, but it is chock full of tips for maintaining job security. :-)

I'm not really a human, but I play one on earth. Cogito ergo sum a bum
  • Comment on OT (funny) How to write unmaintainable code

Replies are listed 'Best First'.
Re: OT (funny) How to write unmaintainable code
by imp (Priest) on Aug 22, 2006 at 15:11 UTC
    You could also use thedailywtf.com as your person snippets collection.

    this is my personal favorite.

Re: OT (funny) How to write unmaintainable code
by samtregar (Abbot) on Aug 22, 2006 at 17:53 UTC
    This one is particularly applicable:

    12. Underscore, a Friend Indeed : Use _ or __ as an identifier.

    Sob...

    -sam

Re: OT (funny) How to write unmaintainable code
by Jenda (Abbot) on Aug 24, 2006 at 16:38 UTC

    BTW, I'm not sure it was to increase their job security (it definitely did not work), but the indians I inherited my main project from must have read some parts this document using some time machine or something. A perfect example was eg. the two ASPs for the global and per-job-board field forms. Both those pages used variables j, k and l to count the inputboxes, pulldowns and textareas in the form. They even passed the counts to itself upon submit. The catch was that what was j on one page was k on the other, etc.

    Next great thing was that they always ignored errors. Something went wrong in the stored procedure? Too bad, the data access object ignored the error and (tried to) behave as if everything worked. Something exploded within the database access object? Too bad, the ASP code never checked the return values, much less try to show or log the details. So everything looked like it was working. As long as you did not try to find the supposedly stored data later.

    Consistency? Don't be silly! Some stored procs started with Get some with Fetch for no apparent reason, some of the methods of the 26 database access objects calling those procedures started with Get and some with Fetch with no relation to the verb in the procedure name.

    Mispelings? I think I'll never know the proper spelling of commission ever again. Comision? Commision? Comission? Commission? They used all those versions. "The database column is JobComission? Let's name the variable Commision then!".

    Speed? The Status column of the largest table in the system was a varchar with values "delivered", "notdelivered" and "deliveryfailed". And I assure you they searched through the table looking for "notdelivered" rows all the time.

    There were parts of the system that I could not for the life of me understand and fix so I ended up deleting everything all the way down to database tables and started anew. ... Yeah I was lucky, they barely finished that part so it was easy to convince the application admins that it will be better to rip out the tumor, start anew and have them reimport and resetup the stuff they succeeded to force in.

Re: OT (funny) How to write unmaintainable code
by explorer (Chaplain) on Aug 22, 2006 at 18:37 UTC

    Of Perl:

    22. Avoid {}
    : Never put in any { } surrounding your if/else blocks unless they are syntactically obligatory.
    If you have a deeply nested mixture of if/else statements and blocks, especially with misleading
    indentation, you can trip up even an expert maintenance programmer. For best results with
    this technique, use Perl. You can pepper the code with additional ifs after the statements,
    to amazing effect.
    
    ...
    
    Perl Only
    : Use trailing if's and unless's especially at the end of really long lines.
    
    B^D

      Except that the "advice" 22. is not applicable to Perl since the {}s are always obligatory for if()s. The if statement modifier is a completely different beast. Though code like this:

      foo( 1, 2, s/sdfgdgI&^%#GG*&T$#/WRUGSkyug/) if ($x == 5);{ $gotcha->('dude'); ... }
      could cause some misunderstanding ;-)

A reply falls below the community's threshold of quality. You may see it by logging in.