Scott Mattocks has started off his series about the LUCID development methodology (one he recently proposed) with the first article covering "L" for Logging.

Communication is the only way you can tell if an application is feeling well or is about to fall apart. If your application can’t talk to you, you have no way of helping it to feel better. The L in LUCID is for logging. Logs are how applications speak. They capture information that allows us to pick up on those little signs and act early enough to make sure the application doesn’t come down with the flu. If you don’t have good logging throughout your system, the best you can do is react to your application falling over. A silent application is an application destined to cause midnight surprises for you and your operations team.

He talks about the difference between "just logging" and "correct logging" as well as a recommendation for the different levels: trace, debug, info, warn and error.

Letting you know that something went wrong is really only half of a log messages job. The other responsibilities of a log message are to allow you to accurately reproduce the conditions under which the event occurred, and to allow you to fix any data inconsistencies.

New on PHPBuilder.com today Leidago Noabeb gives you a pretty comprehensive overview of error handling in PHP - everything from the types of errors to how to control which are output in which environments.

In this article we will be looking at how to handle errors in PHP. Errors are an inevitable part of software development, and accordingly, we will be looking at the various error types and demonstrating how to handle them. If you intend to run any of the sample scripts in this article, please make sure that display errors is turned on in your PHP initialization document (php.ini).

The article talks about the types of errors PHP uses (syntactical, runtime and logical) and shows how to handle some of the most common issues with them. It also talks about the different error reporting levels (ex. E_ALL, E_WARNING, E_STRICT) and includes the code for a simple error handler class that switches off and handles each type differently.

Unit testing in PHP applications is growing more and more in popularity, so much so that some developers get into it, test all of their code and aren't exactly sure when enough is enough. Jim Plush has a suggestion for those kinds of testers - consider the cyclomatic complexity.

To illustrate, he gives a simple example of a function with only a function call and return inside. This has a cyclomatic complexity rating of 1 (the lowest). Now, start adding in ifs, loops, and other ways for the data to go and you start adding more complexity levels. Jim suggests that this can be another useful unit testing measurement - one more unit test for each level of complexity.

He also notes a pleasant side effect of this sort of classification:

Unit testing in PHP applications is growing more and more in popularity, so much so that some developers get into it, test all of their code and aren't exactly sure when enough is enough. Jim Plush has a suggestion for those kinds of testers - consider the cyclomatic complexity.

To illustrate, he gives a simple example of a function with only a function call and return inside. This has a cyclomatic complexity rating of 1 (the lowest). Now, start adding in ifs, loops, and other ways for the data to go and you start adding more complexity levels. Jim suggests that this can be another useful unit testing measurement - one more unit test for each level of complexity.

He also notes a pleasant side effect of this sort of classification: