PHP Freaks Content

10 Ways to Avoid Writing Crappy Code

Fri, 03 Jul 2009 14:15:32 +0000

1. Learn OOP and common OO principles

This is an absolute requirement. If you are still coding procedural, this is no small task. What are you waiting for?

1. Employ Test Driven Design

Code that is buggy or simply doesn't work at all can safely be considered "crappy code". TDD gives you the confidence that your code works, and the side effects force better and more flexible software design.

If you are not familiar with TDD yet, and this post has prompted you to try it, be warned: at first it will seem very cumbersome. What definitely will help is this piece of advice, which is at the core of Test Driven Design: don't write tests afterwards, write them first. Without going to much into the details, and somewhat simplified the general mantra is this: write a test first, make it work by writing the application code, refactor, write another test, make it work, refactor, etc etc. It's a cycle. The application code follows the test code, not the other way around.

I recommend PHPUnit. It has the most features and the largest adoption.

2. Refactor, refactor, refactor

Refactoring means "to improve the design of existing code". Making changes to code results in an increasing loss of quality of that code, this is known as "software decay". To battle this phenomenon, you have to constantly evaluate if the code hasn't lost it's quality, and look for opportunities to improve the design beyond it's original. But there's a catch. And it isn't the time that refactoring takes, if you do it properly you'll save those hours by having avoided software decay. It is the risk of change.

I can understand if you are hesitant to change code that works (at least for now). But this is where number two comes back into play: as long as you've written the right tests, you can make sure your changes don't break anything.

3. Simpler is better

Your mind should constantly be waging a battle between simplicity and flexibility. Avoid unnecessary complication.

4. Use Design Patterns

Design Patterns describe real world software design problem and solutions. Make sure you are familiar with them, buy some books. If you encounter a design problem that seems familiar take your trusty GoF and PoEAA from the shelf and look it up.

5. Don't Use Design Patterns

Once you are familiar with Design Patterns, or even just with the existence of them, it can be tempting to start sprinkling pattern implementations over your application code, just because you can. Don't. Remember a Design Pattern consists of a problem and one or more solutions to that problem. Until you have the problem, don't use the solution.

6. Accept the limitations of your language

Believe me, I know that as a programmer it is difficult to accept limitations on bending your code to your will, but trying to change the behaviour of PHP is not the solution. PHP has limitations, you'll have to live with them. If you try to "patch" them, chances are you will do more harm than good.

7. Pretend you are writing a book

It has been said that "code should be easy to read rather than easy to write". Maybe somebody else will need to understand your code at some stage. Maybe two years from now, you will revisit this code and need to re-learn it's inner workings.

Semantics, meaningful docblocks and clear execution flow are everything. Imagine reading an instruction manual without pictures, filled with meaningless abbreviations, and with the pages in arbitrary order, without page numbers. That's how someone, maybe you, will feel if you ignore this advice.

8. Peer Review

Believe it or not, you don't know everything and you aren't always right. Nobody is. Getting a "second opinion" can only improve the end result.

9. E_STRICT is your friend

Make sure your code runs properly with E_STRICT turned on. Although, if you have gotten this far, I don't think that will be a problem.

10. Create a distinction between "source code" and a "build"

Even though PHP is an interpreted language, this is an important distinction in my opinion, even though practically noone employs this in the PHP world. A build in PHP is a copy of (part of) the source code, which includes assets like HTML, CSS and JavaScript, and is stripped of anything not necessary for running the application. Maybe your build is a Phar file, or maybe you have combined some source files into a single file (like the guys at Doctrine do). Maybe you can provide different build of the same project to server different purposes..

How does this help you avoid crappy code? It allows you to have the source code and build differ, avoiding any compromises you might be tempted to make to facilitate runing or developing the application. Bonus points if you allow the user to choose between placing everything in the server document root or just a bootstrap and the static files.

There are various build tools available, personally I use PHPUnderControl, which is a patch for CruiseControl and gives you a variety of build server features. It uses Ant by default, but I also use Phing.

10 Signs of Crappy PHP Software

Thu, 02 Jul 2009 11:10:56 +0000

Like it or not, as a professional developer, sooner or later you are going to do some customising (if you are lucky, "extending") of existing software.

If you are not familiar with the software, it is good advice to look into it before accepting the job. I had to learn that the hard way. But how do you recognize crappy applications without getting knee deep into the code? 10 pointers to identify crappy PHP software quickly...

1. The software tries to reinvent the object model, or "fix" language features.

See if you can find a class called "Object". If you find it, it's a pretty clear indication that the author is in the business of trying to reinvent the object model (most commonly because of his own lacking understanding of OO). It is safe to assume that his "fixes" won't stop there. Unplug your phone and hide under your desk.

2. The code includes user defined global variables

A search in the code for "global" or "$GLOBALS" may reveal something like this:

global $database, $my, $mainframe;

The infamous global variable. If you can tell me what those last two variables contain you are either intimate with the software I pulled it from, or you're psychic. Unlimited bonus points if you can say what code has had it's claws on it before execution flow got to this point. In short, steer well clear.

3. Scattered HTML and SQL

Search for some common SQL and HTML strings. You should be able to determine very quickly whether these are appropriate places for HTML or SQL. If you find HTML and SQL in the same file, "crappyness" is most definitely confirmed.

4. Classes do too much

Find the 3 largest class files by bit size. Take a look at the class name. Does it indicate a distinct responsibility? Look at the methods. Are the tasks they perform closely related? If not, run away screaming.

5. Lots of properties are public or lots of properties are static

If lots of properties are declared "public static", triple your quote. If I have to explain why, maybe there's an open position on the development team of the software for you.

6. Multiple levels of inheritance

More than 2 levels inheritance should be avoided like the plague. I stake my life on the resulting objects having too much unrelated behaviour (ok, maybe not my life, but if you find a proper use of more than 2 levels of inheritance, I'll buy you a beer).

7. The authors try to use Design Patterns

Whether or not the authors have a clue is easily determined by searching for some of the most common design patters. Search the code base and/or documentation for "factory", "decorator", "strategy" etc. If present, you can pretty quickly determine whether the authors know their stuff or are trying to look interesting. That is, if you know how the code should look. If not, refuse to take the project until you do.

8. The software messes with the error level

Well written applications run fine at any error level. Searching the files for /error_level$.*$/ should do the trick. In case of hits, try replacing the value with E_STRICT. That's little more than a formality though.

9. In the code base, there is a directory called "core"

This is usually used as an excuse to have the whole application dependent on whatever is in there. Despite the appeal of the term (it does make the contents sound pretty cool and important), defining a "core" is a sign of bad design.

10. The software uses it's own template language.

Be afraid. Very afraid. These guys are definitely in the business of reinventing the wheel. Ignore this warning and you will find yourself spending the better part of a day simulating a "for" loop.

Using MySQL Administrator with WampServer

Mon, 22 Jun 2009 16:38:35 +0000

For those readers who do not develop PHP on Windows platform WampServer is probably the most popular Apache + MySQL + PHP package for Windows. MySQL Administrator on the other hand, is a part of MySQL GUI Tools package.

The problem with this pair, is that they don't want to work together. At least not right out of box. MySQL Administrator fails to find mysql service process as installed by WampServer. This leads to infamous 'Could not find settings' error message.

You still will be able to use MySQL Administrator, but some of its features will be unavailable - among them quite important 'Startup variables' that lets you configure your server.

The reason is simple. WampServer keeps MySQL's config file in a directory, that is not checked by MySQL Administrator's searching algorithm.

Luckily, the solution is also simple.

Open registry editor
Windows XP: Go to Start > Run... type in regedit and press Enter
Vista: Go to Start, type regedit into search box and press Enter

A word of warning: be careful when using registry editor, as you might break your system if you change wrong variables.

Using tree on the left go to:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\wampmysqld

In the window on the right find ImagePath variable, double click it's name.

In the dialog that opens you should see something like this:
c:\wamp\bin\mysql\mysql5.1.33\bin\mysqld.exe wampmysqld
(MySQL's version may vary)

Change it like this:
"c:\wamp\bin\mysql\mysql5.1.33\bin\mysqld.exe" --defaults-file="c:\wamp\bin\mysql\mysql5.1.33\my.ini" wampmysqld
(be careful not to miss any double quotes!

Close registry editor, then restart you MySQL server from WampServer's tray menu.

MySQL Administrator should work fine now.

That would be it ;)

----

MySQL Forums post, where I've found this solution

SSH Auto-mount Network Share

Fri, 12 Jun 2009 15:00:37 +0000

(Beware - This blog/tutorial is directed towards linux based users)
When doing any type of work, especially web work, one of the royal pains is FTPing to your server, or any type of file transfer. Well now you can make it quick and painless. Let me introduce SSHFS. There are 3 major components when creating the SSHFS, and I will guide you through creating and installing all of the necessary steps. Now you can mount and use your file system to automatically upload files and folders to your server with ease.

The 3 Major components:

SSH Automatic Login
Install SSHFS
Mount your folder(s)

SSH Automatic Login

Run this command (with the obvious variable substitutions). It should create a public ssh key on your server.

ssh-copy-id [-i [identity_file]] [user@]machine

ssh-keygen -t dsa
ssh-copy-id user@machiner.

Check to make sure it's there, the file should be called, "authorized_keys".

ls -al ~/.ssh/

If you're having trouble with this part, you can reference this tutorial which breaks this component into smaller steps: SSH Automatic Login.

Install SSHFS

sudo apt-get install sshfs

Or use whatever package manager your distribution provides.

Mount

Create a shell script, we'll call it "mount.sh", and add the contents:

sshfs [user]@[your_server].com:/dir/on/server /dir/to/mount

Run the script:

./mount.sh

Go to the mounted directory and run the 'ls' command to make sure all of your files/folders from your server show up in your local directory.

After you have this successfully working you should at it to your startup scripts.

System >> Preferences >> Sessions >> [add_a_new_entry]

You should be all set. You should have an automatic SSH login (no prompt for a password) from your computer to your server and a mounted folder to your server that acts as an automatic FTP client. The files in your mounted directory should be synced with that of your server. Now all you have to do is move or copy your desired files/folders into the mounted directory, and voila, they're on your server.

MySQL University: Boosting Performance With MySQL 5.1 Partitioning

Fri, 29 May 2009 18:29:03 +0000

It's been some time some time since we had a MySQL Uni session subject that could be interesting to an 'average' PHP developer. The one that's going to take place next Thursday will definitely be of this sort.

Introduced in MySQL 5.1, partitioning lets you divide your tables into smaller chunks of data... while still keeping them in one table. No more need for `invoices2006`, `invoices2007`, `invoices2008` tables to cope with archival data, no more wicked UNIONs. Now you can tell MySQL to keep invoices (or whatever you need to keep) from one year separate from all other years, thus improving queries that only deal with records from one year.

That's just a simple example, as there are much more to partitioning than that. I urge you therefore to attend MySQL Uni's Dimdim session this Thursday, June 4th at 13:00GMT.

The session will be presented by Giuseppe Maxia a.k.a. The Data Charmer. I attended one of his sessions in the past, and he seems like a very interesting person to listen to.

Check the MySQL University home page for details (and possible last minute schedule changes!)
For more information about MySQL University, see my introductory post