Chapter 2. Anti-Patterns

Here's where we start on anti-patterns; before you get your hopes up thinking I'm about to tell you something amazing that will wonderfully streamline your code without using design patterns, I won't be doing that here (did I mention I'm great at crushing hopes and dreams?). Anti-patterns are, in short, things you don't want in your code.

Speaking of crushing hopes and dreams, should you ever have a junior developer, anti-patterns are also a great way of teaching methodologies that should be equally avoided. Learning anti-patterns also can boost the effectiveness of code reviews; instead of debating code quality on the basis of personal opinions, you can have an external source to consult on code quality.

Anti-patterns constitute a terrible method of resolving a recurring problem that is usually ineffective and risks being highly counterproductive. They can then create technical debt as developers must later struggle to refactor to resolve the initial problems but hopefully use a more resilient design pattern.

We all have encountered Spaghetti Code; one contract developer I worked with exclaimed to an ever more demanding product owner in the face of high technical debt: "There is so much spaghetti I might as well open a restaurant!" Spaghetti Code is where the control structure of a program is barely comprehensible as it is so tangled and over-complicated and it may be described as an anti-pattern. One of the major criticisms in PHP 5.3.0 was the implementation of goto operators in the language. Indeed, those critiquing their implementation claimed goto operators would provide yet another excuse for more Spaghetti Code in PHP.

Gotos were highly controversial in PHP, with someone even going as far to report it as a bug, stating: "PHP 5.3 includes goto. This is a problem. Seriously, PHP has made it this far without goto, why turn the language into a public menace?"

In addition to this, the submitter of the bug report listed the expected result as: "the world will end" and the actual result being "the world ended". Despite this, goto operators in PHP are heavily restricted so you can't just jump in and out of functions. Some people also argue that they are useful in finite state machines (essentially something with a binary output based on multiple inputs), but this is also controversial; so I shall allow you to make your own judgments about them.

You may well have experienced copy and paste programming, where whole blocks of code are copied and pasted in a program; this is yet another example of bad software design. In reality, developers should be designing their software to create generic solutions to problems instead of copying, refactoring, and pasting bits of code to fit a situation.

I will introduce this chapter with a section on why learning anti-patterns is important. During this chapter, I will discuss not only traditional anti-pattern-related software design but also anti-pattern-related web infrastructure and management styles. In addition to this, I want to discuss some PHP-specific anti-patterns, or flaws in PHP, which you may need to compensate for in your own code.

This book contains a dedicated chapter on refactoring towards the end; if the process of refactoring is of interest to you, this chapter will help lay the foundations of the ideas you might want to start thinking about; in addition to this, the chapters specific to design patterns may help you realize the code you might be eventually aiming for. In the chapter dedicated to refactoring, we will also cover some code smells, which can help you discover anti-patterns in codebases you're maintaining.