Joseph Piché, Web development professional with expertise in PHP, MySQL query optimization, Ajax, and XHTML.

Any programming environment with more than one person working on the same project requires communication; it is an essential part of getting a job done efficiently, and it is common sense. But while normal business communication includes writing, speaking and body language, programming communication also includes readability of code along with good documentation.

Having experience with coding in a large project with other people, I clearly see that indentation is a large part of readability of code. It is extremely important to be consistent with spacing regardless of the language. However, whether to use tabs or spaces for indentation is up for debate. In fact, the issue of tabs versus spaces is a highly debated issue; a simple search will show that. Even so, it is important to have a clearly defined rule when engaging in a project with other people.

To show the importance of this many different open source projects define strict guidelines for indentation. To list a few:

• Style Guide for Python Code
• Python Style Guide for C Code
• Zend Framework Coding Standard for PHP
• WordPress Coding Standards
• WebKit Coding Style Guidelines
• Flex SDK coding conventions and best practices

Most of these say 4 spaces for per indentation level, and all say to never mix tabs and spaces. I do 4 spaces; my programming team at work has agreed on 4 spaces—it works really well in pretty much all cases. All good editors have ways to make this easy to do using the tab key too.

More than likely the language you code in already has some guide already. Please follow it, and remember what the Zen of Python states: “Readability counts.”

PHP class methods and variables can be declared as static similarly to how Java static methods and variables work. As often as possible I try to stay away from anything static in PHP, since it can lead to confusion, bad program design, and in some cases memory management problems. But sometimes it actually does make sense and more often than not just getting things done is more important than doing things correctly.

However, PHP 5.3 introduced a lot of cool new features like namespaces and something called “Late Static Bindings” via a new keyword. But what is Late Static Binding and how does it differ from how PHP before 5.3 works? The reason the new static keyword was added is to allow for intuitive static references involving inheritance.

Before 5.3, PHP used early static binding: the process of resolving any static references to the class where it was initially declared. Clear as mud right? This is best shown by the code example from the PHP documentation.

<?php
class A {
    public static function who() {
        echo __CLASS__;
    }
    public static function test() {
        self::who();
    }
}

class B extends A {
    public static function who() {
        echo __CLASS__;
    }
}

B::test();
?>

The above code will output A not the (maybe) expected B. Replacing self with static in the example will output B, but only in 5.3 and above.

Since none of the servers I work with have 5.3, and some are even lacking 5.2, I cannot take use of the static keyword in my code. But even so, I feel like I understand PHP better now that new feature is available since this clearly shows that using self in any version will use “Early Static Binding.”

I’ve been working at KASA Capital for about 7 months and I feel like I’ve gotten a good handle of some of the more “gritty” details of how PHP works. Unfortunately though, it means I have a running list of annoyances with the language—some more difficult to deal with than others.

1. Keywords are case-insensitive. Being able to write the word true using uppercase or lowercase may be aestheticly useful depending on the context, but I don’t think there would be any situation where writting tRuE or TRue would be a good idea. The last thing I want to see when optimizing someone else’s code is variable-case keywords. Even using all uppercase keywords is highly suspicious, and when I actually saw this the other day, I found the code almost unreadable. I also think that having case-sensitive keywords in PHP would improve parser times, but I haven’t tested this theory. What I do know is that other interpreted languages like Python have strict rules for keywords, and Python code tends to run much faster than PHP code (of course this is not a proof though and may actually have no correlation).

2. isset(), unset(), and NULL are confusing. A while back, I wrote a whole bunch of Python code. Transitioning back to PHP for work was difficult first because of the semicolon use in PHP, but second because of PHP’s (lack of) variable declaration. Technically, the documentation is very specific, but most implementations have a low setting for the default error_reporting level so many programmers have learned to be lazy with variables. After a security audit of your site though, you would probably learn very quickly to code using error_reporting(E_ALL|E_STRICT).

3. When using double quotes with a string, you may include PHP variables in it thus having PHP parse the string. This really isn’t that big of an issue since it is well documented, but most PHP programmers I’ve run into don’t understand that calling the parser takes additional resources which may in turn slow down your code.

4. Magic Quotes. If you have ever had to deal with magic quotes you will understand that this is the single most terrible aspect of the language to ever happen. The theory of it might have been okay, but in practice it is extremely frustrating–not to mention that against recommendations, debian (and thus Ubuntu) packages of PHP have magic quotes on by default. I am so glad this was deprecated in 5.3.

5. I can’t echo HTTP headers. The only way to manipulate HTTP headers is to use the header function. Under most circumstances this is okay, but there are a unique instances like streaming content in a proxy-like manner where the headers are important and it would be too intensive to parse the stream, so I would like to simply be able to echo them. When using PHP in CLI mode, I can use the -q flag to turn header output off, but this is not available in CGI mode, which most people use.

Even with all that, I do still use PHP at work; but constantly trying to write clean, efficient code goes a long way.

This is my apology to users of Internet Explorer version 6. If you are viewing this site in that browser, you probably think that I am a terrible web designer. The real reason my site looks terrible (that is the side bar is at the top and is not a set width) in Internet Explorer version 6 (and earlier) is that the rendering engine of that browser is antiquated and does not recognize CSS commands margin:0 auto; or max-width and nor does it correctly render float, all of which every other modern browser including Internet Explorer version 7 displays correctly.

I don’t understand why you would freely choose to use Internet Explorer at all, but if you are, I beg you to take a look at one of the better options: Mozilla Firefox, Google Chrome. Of course if you are an Apple user, Internet Explorer hasn’t been an option for a few years.

In case you just think me lazy: my full-time job is writing PHP, XHTML, Javascript and SQL, so when I get home, I don’t spend that much time coding. When I built this theme, I only spent a few minutes on it here and there; so I actually just forgot to test it in really old browsers. But yet again, I feel less-than pleased with the theme, so hopefully on the next rendition I will get around to fixing the site in Internet explorer 6.

I have been a loyal customer with Verizon Wireless for about 4 years for a simple reason: they have better coverage than anyone else. This well-advertised fact is not disputed by other companies, and I can personally attest to it, having lived in North Dakota for a 5 years.

But they are behind the times and just don’t understand customers. When I buy a phone with Bluetooth, I expect to be able to use that functionality. No. With my Bluetooth-capable phone on Verizon, they would not allow me to transfer pictures off my phone via Bluetooth.

So after sampling a bunch of phones, I decided on the Pre with Sprint. I will be saving about $30 per month over comparable Verizon plans. (I don’t understand why their plans are so expensive either.) So far both my wife and I love our new phones, and soon I hope to figure out how to write blog posts from my phone.

So at last, au revoir Verizon.

I’ve previously talked about my switch to using Google Chrome and my primary web browser, and for a few months of almost constant use—even to type this post—I have enjoyed it. Chrome’s speed increase over Firefox not only relieves frustrations, but it increases my productivity. Pages load faster, a DOM viewer and Javascript inspector is built into the browser, it is open source, and there is a decently stable release branch for Ubuntu. And, within the last few weeks plugins were available for it in Ubuntu, so Flash works now.

But while all that sounds awesome, I unfortunately cannot remove Firefox yet. Two reasons:

• Using Firebug in Firefox is the only way I know of to view the response of an AJAX call without hard-coding in outputting the response via an alert() or something. It is very frustrating, but Chrome’s document inspector only tells you where an AJAX call was made to, not whether it succeeded or failed, or what the response was. This is crucial to debugging web apps.
• Firefox is a mature project and very, very rarely has any problems. It’s true that Firefox is indeed a tad bit slower at just about everything, but I almost never have problems with it and often have to switch to open up Firefox because Chrome has crashed or is behaving awkwardly.

At work I use Firefox 3.5 on Windows, and that seems to almost keep up with Chrome, so once Karmic (Ubuntu 9.10) is released, I’ll have to give it another try.