In CodeSniffer, a coding standard is basically represented by an empty class that extends PHP_CodeSniffer_Standards_CodingStandard. I could not get the CodeSniffer to find my coding standard, though, and found the documentation lacking about where to put it, how to name it, and how to refer to it in the --standard switch.

After an email to Greg Sherwood (developer of the package) Stefan figured out his issue and has shared the solution in this post (step by step).

PHP_CodeSniffer is a PEAR package which detects potential coding problems and enforces your style guide. The default is the PEAR coding standard, but you can easily change that.

His method requires the creation of a custom "FooCodingStandard.php" (named whatever you'd like, of course) that contains a class/method defining the "sniffs" you'd like to use for your standard. Use "pfm" to make it into a package and install it to your system - you'll be all set.

I've just install the last version of PHP6 dev and I've decided to test the famous new feature, the PHP Unicode Support. I will not explain new things about PHP6 or Unicode or TextIterator, it's just my discoveries test on this features.

He steps through the process he followed - enabling Unicode support, testing various output methods (including just an echo and using the TextIterator) as well as some of the manipulation methods (next/first/current) that can be used to get certain characters out of a string.

When it comes to coding style, there are are various ideas about how you should write the individual lines of code. The usual argument is about "how long should a line of code be"? There's more to it than that, though. Developers should also take into account line volume ("number of lines") and line density ("instructions per line").

He mentions the PEAR style guide when talking about line length, reading code like and sentence in line volume/density and how the "shorter is better" concept can be pushed to its extreme limits taking code into the unreadable zone.

Before jumping into the development of a Zend Framework coding standard for the PHP_CodeSniffer Pear package, I spent some time revisiting and compiling the available Zend Framework coding standards into a handy one-paged Pdf document.

You can download the file here or, if you want something a bit more "spread out", check out the coding standards on the Zend Framework website.

When we have a multidimensional array we have to make some recursives function to parse it. A simple way to get the keys and the value of this type of array is to use the SPL library of PHP.

A code example is included, parsing through a recursive array to output each of the key/value pairs it contains (and using only about five or six lines of code to do it).

Today I discovered a good tool for beautifying existing PHP Code. It works via a web interface. You can either upload a script or directly input it. The code is beautified according to the PHP PEAR Standard Requirements. It does not change or debug your code in any way.

He lists the things it can do for you and your code including setting indents to four spaces, uses the "one true brace" style for function definitions, and removes spaces between things like function calls, parenthesis and beginning of argument list.

You can check out the application and get information on more of the updates it will make on the project's homepage.

The downloads are broken up into two categories:
Standard build

• php-5.2.2RC2-Win32.zip
• php-5.2.2RC2-win32-installer.msi
• pecl-5.2.2RC2-Win32.zip
• php-debug-pack-5.2.2RC2-Win32.zip

• php-5.2.2RC2-nts-Win32.zip
• pecl-5.2.2RC2-nts-Win32.zip
• php-debug-pack-5.2.2RC2-nts-Win32.zip

All other unix-based developers can download their verions from the official PHP QA website for testing.

Here you will find how GtkWidget standards buttons are built and can be drawn. Here we use ready to use methods from GtkStyle class to draw buttons, checkboxes and handles. You can use theses classes to override standard buttons features. It's also useful to understand how GtkWidgets work. This class study started when I was trying to display a handle and did not found any one.

It's less of a tutorial and more of a code dump, but it gives you a good idea of how all of the functionality can work together.

As of PHP 5.2.1, json_decode() no longer follows the published standards for JSON-encoded texts. Why not? For no reason other than the convenience of those ignorant of JSON standards.

His complaint stems from the results of a vat_dump statement - prior to this version it would give a NULL, but now it returns a "bool(true)" value back, resulting in some breakage of previous scripts. He spends the rest of the post explaining his voyage through the JSON world and how things are supposed to behave. He also digs a little deeper into the var_dump issue and why he thinks it's such a bad thing.