Web Cash

While browsing through dZone the other day, I stumbled on this article – 40 signs you really are a lousy PHP programmer.

While I don’t agree with all of the author’s points, it’s an interesting list of php coding habits to avoid – but that most of us tend to pick up anyway. Here’s a list of my five biggest pet peeves.

5. Output Information Directly in Functions

This is pretty annoying when it’s unexpected. I installed a Wordpress plugin (wp_time_since), and I expected it to return a value to me. I ran into some weird outputting difficulties when I tried to echo the plugin output.

After a few minutes I figured out that the plugin was echo’ing the output for me – instead of letting me store it and output it myself. Give me the information, and let me worry about outputting it.

4. Use $_GET When $_POST Would Be Better

There are appropriate places to use $_GET – such as search queries and simply fetching information from a database. However, any time you’re modifying something in the database you should be using a post method and the $_POST array.

This isn’t 100% safe since people can still spoof your script with their own form or a simple http header request, but at least it prevents the average user from accidentally putting random stuff in the URL and screwing up your day. Use the request superglobal arrays wisely. They’re divided into two separate arrays for a reason.

3. Return HTML, not Data, Strings, or Objects

This kind of goes along with #5. It’d be nice if your function gave me raw output, so that I could style and structure it the way I want to. If nothing else, I’d like to wrap the text in my own paragraph tag, in case I want to give it a class.

2. Misuse Object Oriented Programming

For a lot of web-script programmers, OOP is a strange beast. Why? Because it’s new to PHP.

I come from a C++ background, and OOP is pretty natural to me. Therefore it’s annoying when OOP is misused and abused. It’s not simply a container for functions. You should appropriately use private/public methods. It should make some kind of sense, in an “object” kind of way.

Otherwise, just stick with procedural programming. It’s still a valid way of creating your script – and it may just be simpler.

1. Not Clearly Commenting Code

I hate this. I really, really hate this.

Code should be clearly commented and documented. If I’m wading through the API of a large project, I want a narrative of what the function is doing, what the parameters should look like, and what I’m getting in the end. I don’t have all day to figure out your script – so tell me what it’s doing.

Lastly, there’s one thing he mentions that I really don’t agree with.

The author suggests that templating engines (like smarty) are a waste of time. I originally wondered what the purpose of them were, until I used it to build a module for CMS Made Simple.

Templating engines can be very helpful tools to structure and style your output. They’re also terrific if you want to break down the developer/designer tasks. The developer is responsible for fetching and creating the output, and the designer takes the pre-defined Smarty (or template) variables and places them in the template where they need to be.

I can see why some people wouldn’t like them for small tasks, but they can be immensely helpful. Work with them for a while before you pass judgement.

Tags: comments, OOP, php, programming, smarty