In a new post to the Exakat blog they try to answer the question "how many parameters is too many" when it comes to the structure of the methods and functions in your application.

Now, that is a classic question, that is often a minefield for anyone writing an increasing long list of argument in a method, or simply trying to set up auditing tools.

Obviously, the answer is not immediate. Parameters may be needed, but on the other hands, currying functions allows to reduce the amount of parameter to one for every function. In between, probably exists a reasonable level that is a golden rule, and also very elusive. So, we decided to check the current practice in PHP code.

They started the research with some of PHP's own native functions that took in specific arguments, ignoring those that took an arbitrary number. Next they made a survey of 1900 open source projects to determine the common practice for parameters by function. The results showed that methods without at least one parameter were "less useful" and that a seemingly reasonable amount of parameters is 5. The post finishes with a spotlight of two they found during their research that had the most parameters: a generated class for database interaction and a dependency injection class.

On his site Joe Ferguson (maintainer of the Laravel Homestead project) has posted the first part of a "missing manual" series for Homestead. In this first part he covers the use of site parameters.

In the early days of Homestead there used to be a “params” option at the top level of your Homestead.yaml file. These parameters would be copied into the environment for the virtual machine just like you would set environment variables on your production systems. Laravel ultimately moved to using “.env” files and this feature was removed from Homestead.

Some users pushed back and still wanted to be able to easily push parameters to the individual site’s configuration file (virtual host file) so a new feature was implemented where you could add a “params” key to your Homestead.yaml site definition and they would be copied into the virtual host configuration file.

Joe then shows how to add the params section back into the Homestead.yaml file and get the settings loaded into the Homestead instance (involves destroying the Vagrant box and restoring it).

On the QaFoo blog they have a new post offering some advice on extracting functionality to data objects and reducing the complexity of your application's interfaces.

Extracting data objects from your code will make it easier to read and write, easier to test and more forward compatible. This post shows you the two most common cases where introducing a data object makes sense and how to do it.

The first case covers the extraction when a method ends up with too many parameters. We've all been there and remembering the correct order and values for each (not to mention optional vs required). By making use of value objects you can reduce that down to one or two parameters that act as self-contained "containers" for the same values. They illustrate with a refactor of "product" search criteria into a "ProductCriteria" object. The second example show a refactor away from using an array as an input value and providing a bit more structure with a "Checkout" value object instead.

The post ends with a helpful hint about migrating from one method to the other in legacy systems using a "shim" method to handle the new case right alongside the old one.

Pim Elshoff has a recent post on the Procurios tech blog looking at autocompletion on function calls and an alternative to the "too many parameters" problem.

Some methods have many parameters. Sometimes they start out like that, sometimes they grow like that over time. Even though a maximum of two parameters is preferable, configuration for a method that does a big thing is difficult. Take curl for example; curl has a lot of options and so several wrappers around curl have arisen to deal with configuring it in a more humane manner. How can we keep the clutter of many parameters as low as possible, while maintaining autocompletion?

He gives an example of a function that takes too many arguments and how it's difficult to read (and remember the right order/types to give). He does mention one way that's sometimes used - arrays - but you lose typing checks with that. His best recommendation is to use a fluent interface instead. Not only does it make it more readable but it also works with the autocompletion in most IDEs.

On NetTuts.com today there's a new tutorial talking about a part of PHP that can be quite powerful but isn't used too often - reflection in PHP. Using Reflection you can get information about your actual code and its elements without having to try to parse it yourself.

Reflection is generally defined as a program’s ability to inspect itself and modify its logic at execution time. In less technical terms, reflection is asking an object to tell you about its properties and methods, and altering those members (even private ones). In this lesson, we’ll dig into how this is accomplished, and when it might prove useful.

They provide a little context around the idea of "reflection" in programming languages and then jump right in with a few sample classes. They set up their "Nettuts", "Manager" and "Editor" classes and show how to use the ReflectionClass functionality to get their structure. The examples show how to get the class' methods, their properties and calling these methods using things like invoke and call_user_func.

Gonzalo Ayuso has posted the results of some performance testing he did with bind parameters in a PDO-based request for his application.

Some months ago a work mate asked me for the differences between using bind variables versus executing the SQL statement directly as a string throughout a PDO connection. Basically the work-flow of almost all database drivers is the same: Prepare statement, execute and fetch results. [...] What's the best one? Both method work properly. The difference is how databases manage the operation internally.

He gives two code examples, one with the bind parameters and one without, and the benchmark code he used to generate his statistics. It uses a PDO connection to execute several statements in a row both with bind parameters and without, measuring the time (with microtime) and outputting the results. His results show that while the simple update is faster, the bind parameter method has the added benefit of reusability for multiple queries.

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.

In an effort to breathe as much life into an old bit of software he was having to update, Harry Roberts worked up a list of things that he sees can make things a bit more "programmer friendly" when it comes to using classes, methods and interfaces in your code.

His list of four is:

• Doc Comments
• Flexible Parameters
• Use method Entry contracts
• Be Stateful and Refactor

The "Doc Comments" is pretty obvious, but some of the others need a bit more explaining. Being flexible with your parameters is more about requiring the least from a developer, "entry contracts" being the restrictions to let the developer know what you're expecting and refactoring commonly used functionality into a easy, single point of contact.

On the Shadow Fox Network, there's a new tutorial that shows how to combine the Apache mod_rewrite functionality with some PHP functions to make passing variables over your rewritten URL easy.

You can't pass variables well without adding more commands to mod_rewrite. So here you'll learn to add unlimited parameters to your links with only one simple PHP function.

He starts with a mini-refresher course on the contents of the previous article and moves to the simple rewrite example that makes it possible - a two line statement. Then, it's on to the PHP - again, a simple function that does things simply, grabs all of the parameters from the URL and splits them out into a global parameters array. He even includes a simple example as a tutorial you can try out with the demo.

On the Shadow Fox Network, there's a new tutorial that shows how to combine the Apache mod_rewrite functionality with some PHP functions to make passing variables over your rewritten URL easy.

You can't pass variables well without adding more commands to mod_rewrite. So here you'll learn to add unlimited parameters to your links with only one simple PHP function.

He starts with a mini-refresher course on the contents of the previous article and moves to the simple rewrite example that makes it possible - a two line statement. Then, it's on to the PHP - again, a simple function that does things simply, grabs all of the parameters from the URL and splits them out into a global parameters array. He even includes a simple example as a tutorial you can try out with the demo.