Stefan Priebsch recently posted about his struggles with creating a custom coding started with the PHP_CodeSniffer package:

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).

According to a new post on the tilllate blog today, "unit testing makes coding more fun":

"Unit testing is a test that validates that individual units of source code are working properly", that's what Wikipedia says about unit testing. That's general knowledge.

But what motivates me even more than the increased software quality is that it saves me development time. This sounds odd as you might believe that TDD means writing more code.

A real-life example is included (an internal invoicing system) with the steps they'd follow to test it normally via the browser (slow) or through the automated tests (fast!)

In a new blog post, Paul Jones looks at three aspects of coding style - line length, volume and density - and how different people have different assumptions as to what's "right".

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.

Raphael Stolt, in working on his component for the Zend Framework (based on the PHP_CodeSniffer PEAR package), pulled together all of the information Zend provides about their coding standards into one place.

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.

Spurred on by some previous benchmarks [pdf] from Ilia Alshanetsky, Joakim Nygard decided to run some his own benchmarks on the same sort of functionality.

There are numerous discussions in the blogosphere about whether to use echo versus print, if for() is faster than while(), etc. and though the gains are usually very small, I decided to add my thoughts to the debate. I found an article on optimization through coding habits in Ilia Alshanetsky's zend performance slides.

According to his results:

• Calling require_once() 10000 times in a for() loop with an empty file is 4x faster.
• With a simply autoload requiring a class and 10000 loops of new Foo() versus require_once('foo.php'); new Foo() shows that __autoload() is ~3.7 times faster.
• If a class method can be static, declare it static. Speed improvement is by a factor of 4.
• Avoid function calls within for() loop control blocks
• Always, always quote array keys.
• Get rid of 'harmless' error messages - they take time to generate and output.

I am not out to prove Ilia wrong - he knows PHP better than most - and for all I know, they could have optimized those very functions in PHP 5.2. [...] It would appear that there are improvements, albeit small, to achieve from minimal effort. Plus I was surprised by the discrepancies I found compared to Ilia's recommendations.

On the PHPKitchen site today, Demian Turner looks at a handy utility to ensure that the coding standards in your documents are all passable - PHP_CodeSniffer.

There was a fantastic CS helper package released at PEAR this week, PHP_CodeSniffer. The package, which requires PHP5 and is nicely coded, puts a phpcs script in your path so you can pass files or directories to it to get your CS validated.

The results are detailed and processing is surprisingly fast considering how many tokens are being parsed.

Demian gives an example of what the validation process looks like and why he finds the entire package particularly useful.

In a great new post from Alan Knowles he takes a look at code reviewing, specificaly in a PHP environment.

He breaks the post up into phases (one through four) with the steps outlined along the way (including the "oh sh*t, it's getting urgent, we better fix the delivered code and make it work well enough for the client to start testing" phase). Phase four is the largest, being the bug finding and fixing stage, some of the more intensive (and sometimes numbing) times of development.

He also includes a good, long list of some of the codeing standards he's accumulated over time, including:

• Not creating PHP includes with functions in them!
• Never hard code email subjects etc. in code, use templates.
• Not using libraries that where not specified.. or using non-PEAR libraries when PEAR ones are available...
• Everything extends the base class, even code run via cron jobs.

He also talks about using print rather than echo, exiting on XMLHttpRequest calls, shortcuts in Javascript, and cloning dataobject arrays over creating simple structs.

When someone talks about PHP and drags up the old "but it doesn't scale well" argument, drop them an email with this new article from the O'Reilly ONLamp.com site that might change their minds. In it, they share some information they gathered (spurred on by James Gosling's comments on PHP a bit back) on how one large site, digg.com, has dealt with their huge popularity and scaling their PHP-based system.

They focus mainly on the cost of scalability - whether that be in hardware costs or simply in manhours. He interviews Owen Byrne, Senior Software Engineer for digg.com about some of his decisions on how to handle the explosive growth. They look at what "performance" and "scalability" really are, and some of Byrne's concerns on the matters as it pertains to PHP. They touch briefly on a few topics, including the hardware cost, the database cost, and the actual PHP coding cost of applications.

It turns out that it really is fast and cheap to develop applications in PHP. Most scaling and performance challenges are almost always related to the data layer, and are common across all language platforms. Even as a self-proclaimed PHP evangelist, I was very startled to find out that all of the theories I was subscribing to were true. There is simply no truth to the idea that Java is better than scripting languages at writing scalable web applications. I won't go as far as to say that PHP is better than Java, because it is never that simple. However it just isn't true to say that PHP doesn't scale.

Pass it on...