In a recent post to the PHP-GTK Community site, there's a new presentation on code completion for PHP-GTK in Netbeans (illustrated here).

Jose Antonio Bayona Medina has put up a slideshow demonstrating how to use the basic technique outlined in this chapter to add PHP-GTK 2 autocompletion in Netbeans 6.7.

You can see the presentation in the post or head over to Slideshare and check out this and other presentations by Jose Antonio Bayona Medina about more PHP-GTK work and code completion.

On the Ibuildings techPortal today there's a new article from Lorna Mitchell looking at the phploc tool as a way to analyze your code and pick out a whole selection of statistics.

This has been a feature of PHPUnit for some time but has been released as a separate project in the phpunit pear channel. The nature of PHPUnit means that many of these statistics can be collected while the tests are running, which is why it was added to that tool in the first instance.

Stats gathered include the number of directories, files, interfaces, methods, functions and constants with more details for each (like visibility, actual lines of code contained in them and the cyclomatic complexity). The tool is very simple to use - just call it from the command like and give it a path to your codebase. It does the rest and spits out a text-based report.

In this recent post to the DevCentral blog (from f5.com) they ask why reusable code, one of the foundations of good development (especially in PHP) is so hard to secure.

Being an efficient developer often means abstracting functionality such that a single function can be applied to a variety of uses across an application. Even as this decreases risk of errors, time to develop, and the attack surface necessary to secure the application it also makes implementing security more difficult.

The article talks about a project the author was working on and how, when he came across a need for a component and found one that worked, they were surprised to see how difficult it would be to secure it without adding on extra code bloat. He describes some of the issue and talks about how the development of the component must not have included any thought into things like input validation or filtering. One suggestion is to employ a firewall to sit in front of the entire application and handle all of these things without changes to the code.

On NETTUTS.com today Burak Guzel has written up some good tips on how to make your code much more readable (and easier to maintain in the future. Not all of them are directly PHP related, but they are general enough to be applied in other places in your development.

Code readability is a universal subject in the world of computer programming. It's one of the first things we learn as developers. Readable and maintainable code is something to be proud of in a finished product. We can share it with others, contribute to other projects, and reuse code from applications we wrote months or even years ago.

Tips included in the list cover topics like:

• comments & documentation
• code grouping
• avoiding deep nesting
• using consistent temporary names
• using object-oriented code versus procedural
• effective refactoring

Jani Hartikainen offers a simple suggestion for making your code better - stop adding more parameters.

You need to add some new functionality to your function or class. Let's say you need to remove all objects stored, but optionally also call a method on them. It's pretty simple, isn't it? Let's just add a parameter to removeAllObjects! If you make it true, the additional method is called, otherwise not. Except it's not really such a good idea at all...

He points out that there's nothing wrong with parameters, it's their overuse that can cause the issues - if, in using them, it's unclear what they're doing, don't use them. He includes a few rules for making good use of parameters: less is good, relationship to the function, parameter order importance and using the language's parameter handling to your advantage.

Patrick Allaert has put together a shell command that can take your PHP4 code and replace its current constructors with PHP5-formatted ones.

It assumes your classes are always declared with the class keyword starting at the beginning of the line and that your files have the .php extension.

It uses a regular expression in a perl command to search through the current directory and look for the ".php" files to replace the "function ClassName" sort of thing with a "function __construct".

Jani Hartikainen has posted some of his opinions about code commenting in a response to this post from James Carr claiming that code comments on fresh code is a bad idea.

James puts it quite well: When you write comments, it would be much better idea to just talk with your coworkers about it. He uses "excuses" as an example - code which does something that you need to explain, or says something like "Here we do X but we should really do Y" While I partially agree - if you're not sure which approach you should use, or whether your approach is correct, talking with your coworkers is definitely a good idea.

Jani talks a bit about what he considers good and bad commenting - non-redundant, descriptive and sometimes difficult to remember to do correctly.

In his most recent post Stuart Herbert has a suggestion that can make your development life simpler and make debugging less of a headache down the road - isolation.

If you know the code well, perhaps you can make an intuitive leap to immediately jump to where the bug is. But how do you go about tracking down a bug when intuition doesn't help? The nature of all code is that larger systems are built from smaller underlying systems and components. [...] Apart from being a strategy that allows you to work on code you've never seen before, this approach also has the advantage that it is evidence-based.

He suggests the division of your application down into the base level of components, sets of "logical points" that make it both simpler to test and more modular for the future. He gives an example of tracking down a bug in a system like this and notes that, with a good set of tests, it can be much faster than some of the other, more traditional debugging methods.

In a new post to his PHP in Action blog Dagfinn asks the question "is bad code good for you?" He wonders if bad code really is a good thing and how it can be split out from the good parts of your application.

This is an interesting idea that struck me as novel. But after thinking more about it, I believe it's not a radical departure from what we're all implicitly accepting, no matter how fanatical we might be about clean code.

He includes a quote from Luke Welling on the subject talking about how bad code, despite the headaches it may cause for maintenance and future development, can be a good thing if it does good for the project.

On the Think Vitamin blog Kieran Masterson has put together an article about debugging PHP applications - everything from error levels out to a few useful tools that can help with some of the more complex issues.

Nobody enjoys the process of debugging their code. If you want to build killer web apps though, it's vital that you understand the process thoroughly. This article breaks down the fundamentals of debugging in PHP, helps you understand PHP's error messages and introduces you to some useful tools to help make the process a little less painful.

He looks at changing the display_errors setting, updating the error_reporting level, the types of errors (notice, warning, etc) and the Xdebug and FirePHP tools.