On the Exakat blog there's a new post sharing six good practices for "use" in PHP. The "use" keyword has a few different places it is used in PHP (like importing namespaced classes and passing in values to closures).

While reviewing code recently, I realized there are no guidelines for use. Every modern code do use ‘use’ (sic), as importing classes from composer or a framework is the norm. There are now quite a few variations in syntax for importing classes or traits. Although the impact on performance is low, as use is solved out, having a clean approach to ‘use’ is important to keep the code clean and readable. Let’s review what are the six good usage of use.

Each of the six tips they share come with a bit of explanation and code to back them up:

• Do not import unused classes
• Alway use alias
• Place all use at first
• Avoid using the same alias for different classes
• Group use expression for easy reading
• Limit the number of use expression

Some of them could be argued as to whether or not they're a "best practice" but it'd definitely interesting to see some tips for the use of this increasingly common little keyword.

Rob Allen's latest post focuses in on something that's been a part of PHP for a while now, back when namespacing was introduced - the "use" keyword. He shares some thoughts, both from others and himself, about whether or not they make code more readable.

I was having a discussion on IRC about use statements and whether they improved code readability or not. [...] Those longer class names make it a little hard to quickly parse what it going on. The [example with "use" statements] is clearly less cluttered, but is at the expense of ambiguity. Exactly what class is User? I would have to go to the top of the file to find out. Should I use aliases? If so, how should I name them?

He went out to Twitter for advice from other PHP developers on the issue too. The feedback from his question came mostly in support of the "use" statements:

• "I think use statements just abstract where the class is coming from. Some people find that useful."
• "I think it's helpful seeing all of the packages used by a class without having to look through the full code."
• "One reason I like them is that I can glance at a file and know dependencies immediately."
• "I do appreciate what you are saying about the indirection use statements introduce."

There's also a bit of talk about "aliasing" with namespaces rather than the full classname, then using the namespace and class name in the code to "minimise ambiguity".

Evert Pot was seeing some weird issues with his MySQL BOOL usage via PDO when he upgraded to one of the latest versions (5.6). Thankfully, he's shared his solution to the problem as well as the symptoms he was seeing when it was causing problems.

I recently updated my workstation to run MySQL 5.6.13. It didn't take very long for things to start breaking, and since I couldn't find any other information about this on the web, I figured this may be useful to someone else. The main error that started popping up was: "Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'my_bool' at row 1' in test.php" This exception happens under the condition that you use PDO, prepared statements and booleans.

He includes a small sample script to reproduce the issue and points out the issue - the default casting of prepared values to strings in prepared statements with PDO bound parameters. He shows two "relatively easy solutions" to the problem - either using integers instead of the true/false PHP boolean or specifying a type with the bindValue call.

Volker Dusch has a new post to his blog looking at the use of references in PHP (or lack there of) and what we, as end users of the language, can do about it. His example looks at mysqli prepared statements.

Even so not every PHP Developers knows WHY we don’t use references pretty much every core function and every somewhat modern framework avoids them so people adapted this best practice. The leftovers in the PHP core, like sort() or str_replace(), are exceptions to the rule. So if the common consensus is, or at least 'should be', that we should not use references then maybe we should start looking for places where they hurt and how we could fix them?

He talks about prepared statements and one thing he sees that makes it a "hard sell" to developers needing a good way to query their databases. He points out the difference in code required between the normal MySQL calls and mysqli (hint: it's more) and shows how to use an abstraction layer to make things a bit easier. He points out the downfalls of using this approach, mainly the performance hit you get (from using his fetchAll method).

In a new post to his blog Johannes Schluter suggests an alternative to using prepared statements in PHP applications using a database - creating a handler method that allows for dynamic queries as well as proper escaping of values.

Now prepared statements were a nice invention some 30 years ago abut they weren't meant for making things secure and so they do have some shortcomings: One issue is that preparing and executing a query adds a round-trip to the server where it then requires resources. [...] With prepared statements you first have to build the list of place holders (the exact amount of place holders (?) separated by a comma, without trailing comma) and then bind the values and mind the offsets when having other values - this typically becomes ugly code.

He includes the code for his alternative, a function using the mysqli extension to let you create dynamic SQL that still uses placeholders and proper escaping to prevent both SQL injection issues and resources problems caused by the multiple hops back to the database.

On NETTUTS.com there's a new tutorial talking about the problem with PHP's prepared statements, mainly due to their flexibility.

There are a couple issues that appear to make these methods less flexible than we’d hope. For one, we must utilize the bind_result method, and pass in a specific number of variables. However, what happens when this code is within a class, and we won’t immediately know how many variables to pass? Luckily, there’s a solution! I’ll show you what it is in today’s video tutorial.

The tutorial is screencast but they've also included the full code ready for cut and pasting into your favorite editor of choice.

On his blog today Andrey Hristov has a quick post that talks about two methods to extend the functionality that the mysqli extension offers in PHP with your own custom code.

Have you ever though about extending mysqli's classes. It's pretty simple to subclass the connection class mysqli. However, subclassing mysqli_result and mysqli_stmt is not so obvious, actually I though that it's even not possible. However, never say never! After discussing mysqli's OO interface for an hour yesterday [...] I found out how one can plug his own classes.

Two code examples are provided - one for extending the mysqli_result and the other extending the mysql_stmt class. You can find more about these and other classes the mysqli extension has to offer in this section of the PHP manual.

When Carson McDonald tried to get multiple prepared statements to work in his MySQLi code for his application, he got a "commands out of sync" error. Luckily, he's found a solution thanks to the store result.

Details about this error can be found in the mysql docs. Reading those details makes it clear that the result sets of a prepared statement execution need to be fetched completely before executing another prepared statement on the same connection.

He gives code snippets that are "before" and "after" examples of what he had to change to get things working. Each time its executed, the "store_result" call is made and the result set is pulled out of the prepared statement.

DevShed continues their series looking at the XDebug extension for PHP with this fifth part looking a bit more at the code coverage functions it comes with.

In this fifth part of a series on using the Xdebug extension to help debug your PHP programs, we'll take a closer look at the xdebug_start_code_coverage() and xdebug_get_code_coverage() functions. Specifically, we'll see how we can extend their usage when working with conditional statements. As always, we'll complement theory with a number of hands-on examples.

They start with a review of the previous tutorial (that started the look at code coverage) and continue on to show how to extend a code coverage class to debug some conditionals and return the results in a simple echoed output.

In a recent post to his blog Rubayeet Islam compared the more traditional way of running a query in MySQL versus a prepared statement with the MySQLi extension.

Consider a PHP-MySQL application where the information of 1000 users is being retrieved from the database by running a for loop [...] in each iteration, the first thing the MySQL engine does is to parse the query for syntax check. Then it sets up the query and runs it. Since the query remains unchanged during each iteration(except for the value of user_id), parsing the the query each time is definitely an overhead. In such cases use of prepared statements is most convenient.

He explains what prepared statements are and some of the advantages around them and includes some benchmarking examples to show the differences - about a five second jump in favor of MySQLi.