WEB Advent 2009 / Unmaintainable PHP

With the recent unemployment rates, everybody realizes that job security is important. The best way to keep a job is to be irreplaceable. If no one can maintain the code you write, you have a job for life. Writing unmaintainable code is a special skill that seems to come quite naturally to certain developers. For the rest of you, here are some tips and tricks to get you started.

First things first

It all starts with the job posting. You should look for the right company, where you can spread your wings and achieve your unmaintainable potential. You don’t necessarily need to be the PHP guru in the company, but it sure helps. Look for job descriptions that mention migrating to PHP from something else, so you know you’ll be calling the shots. Or, search for misguided jobs posts that require 10 years of PHP 5 experience, plus fluency in FrontPage and Netscape Composer.

Once you land the golden opportunity, be vocal from day one. Speak up at meetings; let your opinion be heard. Talk about object-oriented design architectures, enterprise, shifting paradigms, how “good enough” is not good enough, and, of course, your personal commitment to excellence. Make sure everyone consults your opinion on the important initiatives.

The pillars of unmaintainability

Inspired by the most excellent unmaintainable code — a must-read for anyone interested in keeping their job — here are two important concepts you need to grasp and master:

1. Make it impossible for someone to easily change something without breaking something else. The maintainer doesn’t have time to understand your code. Maintainable code means being able to quickly find something, understand how it works, and change it without breaking stuff. You can’t have that. No one should be able to simply search for something and find it where they expect.
2. Your code shouldn’t look unmaintainable, because someone will suspect something. It just has to be unmaintainable. The code should look normal to the poor souls maintaining it, but take them by surprise when they least expect it.

Best practices

1. Ban coding conventions. Endless flamewars have been fought over coding and naming conventions. You can’t have that in your fine organization. You have awesome projects to build, and you can’t afford to spend countless hours in discussion of tabs versus spaces. Plus, conventions are restrictive. If new hires are not used to your conventions, they’ll be miserable. Unhappy programmers are unproductive programmers; explain that to anyone who asks. Let everybody write in their favorite style du jour. As for your own code, rotate your conventions. Go camelCase on Mondays, all_lowercase on Tuesdays, mix-and-match on Fridays, and Hungarian on every February 29th.
2. No comments. Your code is beautiful; it doesn’t need comments. If someone can’t understand it, maybe they are not so good after all. If, by any chance, you’re forced to write comments, then simply overdo it. Elaborately describe the most obvious and trivial code, and skip the rest.

   
   // In the following block,
   // we add two variables,
   // variable a and variable b.
   // Both of them are integers.
   
   // Declare variable a,
   // and assign it the value 1.
   $a = 1;
   
   // Now, declare variable b,
   // and assign it the value 2.
   $b = 2;
   
   // Add the two variables, a and b,
   // declared and initialized above,
   // and assign the result to variable c.
   $c = $a + $b;
       

3. Standardize on Notepad. Let the others suffer and eventually leave the team. You don’t need to listen to them complaining all the time. And, if someone asks why Notepad is the standard, be ready to explain. It comes with Windows — the only OS for today’s productive programmer — and it doesn’t cost anything. I’m sure you’ll find references on the Web that explain how you can use any editor, including Word, to write code for web pages, but Notepad is for real gurus. And, after all, your company hires only gurus.
4. No unit testing. Explain to anyone who asks that you are hired to write high-quality code that doesn’t have bugs, ergo it needs no testing. (A bit of Latin always makes you sound smarter.) Why would anyone in their right mind spend any time writing useless tests that confirm the obvious, that the code works? Some things in life just are — the sky is blue, the sun rises from the East, and your code works, thank you very much. Move on. (Like with comments, if forced to do tests, be prepared to test the obvious, and skip the rest.)
5. No templating. Templating helps separate business logic from presentation. It may make the code maintainable, and you cannot allow that. As Rasmus Lerdorf says, “PHP is a templating engine”. Even if you’re forced to use a templating engine, find a way to misuse it, and put little pieces of business logic in the template, and a carefully crafted mix of HTML, CSS, and JavaScript in the database access layer. In general, strive for a healthy mix of PHP, HTML, CSS, and JavaScript, possibly on the same line of code. Write PHP that creates JavaScript that creates HTML with inline styles. If asked, call this “encapsulation” — your code is responsible for itself.
6. No version control. It’s hard to avoid, but it’s worth it. Demonstrate how it improves communication between team members if you talk about stuff, instead of relying on cold-blooded version control software to resolve conflicts. When you fail to convince anyone, do not despair. You don’t have to commit it all to version control. Keep some code to yourself — small but deadly pieces that will break the project if someone other than you tries to build and deploy. If caught, explain how this code was not yet finished. After all, you only commit code that can educate junior team members on exceptional quality and clever solutions. These boys and girls look up to you and expect nothing but the best!
7. Build a framework. When you build a framework, you inevitably become “the architect,” and your authority is unquestionable. Plus, it lets you add secret conventions — and lots of them, sometimes contradictory ones — that will trip up even the most experienced maintainer. Your framework will take care of everything. No one should bother understanding it; they should be happy you’re single-handedly making development easier and more productive for the whole company. Never release the framework as open source, because the framework is an asset to the company, and the open source community will poke fun at you, and that could be the end of your bluff.

Naming stuff

Your variables should be named mysteriously, often with only one letter. The goal is to make it impossible for anyone to find anything with a simple search.

Class names and functions should be single-character names too. When you must use a normal name, use it all the time — sometimes the best way to hide information is to have too much of it. When reusing the same name — for example, “subject matter-oriented programming” — it also helps if you place parentheses and curly braces on new lines. Claim this improves readability; it also forces your teammates to brush up on regular expressions if they want to find anything in your code. Consider the following example:

$noodles = 1;
class 
noodles
{
    var $noodles = 2;
    function 
        noodles
        ()
    {
        $noodles['noodles'] = 'noodles';
    }
}
function 
    noodles() {
        return new noodles;
    }
$noodles = noodles();
var_dump($noodles);

You can also use strange character sets when naming variables. Cyrillic letters are quite appropriate, because some letters look just like Roman letters, but they aren’t. For example, what do you think the following outputs?

$alert = 1;
$аlert = 2;
echo $alert;

Did you guess 2? Not if the second $alert starts with a Cyrillic а! (Try it.)

Referencing stuff

Even if you define something normally, that doesn’t mean you can’t use it in interesting ways. The weapons to master include the following:

• eval()
• variable variables
• variable class names, e.g., $strudels = 'noodles'; $noo = new $strudels;
• call_user_func()

Any language construct that allows you to treat code as strings is your friend.

// calling abc();
$z = 'A';
call_user_func($z .'bC');

Capitalization

Master letter cases. Function names are case insensitive. Abuse this.

function abc(){
    echo 'abc';
}
AbC();

On the other hand, array keys are sensitive. Abuse this as well.

$a['UseConvetionsOnlyTobreakThem'] = 1;
if (isset($a['UseConvetionsOnlyToBreakThem'])) {
    // Lots of confusing code.
}

Overwrite

Overwrite globals, especially superglobals. Overwrite elements in the $_GET array early; overwrite them often. Same for $_POST. Sprinkle some quiet $_REQUEST overwrites as well. If asked, explain that you’re filtering input to prevent XSS, injections, infections, and other diseases.

Control structures

Mix and match all of the alternative if, while, for, foreach, and switch syntaxes. If asked, explain that you’re training the new hires to really learn the language. All of it.

if ($a > 5):
    if ($a > 4) {
        while ($a > 0):
            echo --$a;
        endwhile;
    }
endif;

Nest ternary operators. Nothing beats concise code.

// Guess the output.
echo TRUE ? 'true' : FALSE ? 't' : 'f';

Inside the body of for loops, increment the $i once again to keep everybody alert. Alternatively, surprise folks by not using $i for loop increment. Ever.

Nest loops. Deeply. Then, suddenly break out of them. Statements like break 2 and break 3 are a pure joy to figure out, especially when mixed with strangely-indented code.

That’s a start!

That’s all for today. I hope by now you’re convinced that you can do it. You, too, can write unmaintainable code. Now your future is in your hands! Can you afford to take the chance of being replaceable by writing predictable, maintainable code?

Translations

This article is also available in Turkish.