For PHP, best practices, I have read somewhere that if you assign your data to a variable it takes almost no memory or resource.

So let's say I have this function that return a count.

public function returnCount($array){
    return count($array);

or if this is better?

public function returnCount($array){
    $count = count($array);
    return $count;
  • 3
    If the function is a simple as the one mentioned here, I use the first style (KISS) if it's more complex I use the second one (easier to debug).
    – K..
    Commented Dec 19, 2012 at 16:40
  • In your example variable just clutters the code. It's definetely clearer without it. In general, I would be happy with return $arr['index'], return $obj->property, return $value + 1, etc. If expression is more complicated and it's result can be named - I would use extra var.
    – scriptin
    Commented Dec 19, 2012 at 16:42
  • Not necessarily a PHP thing, but I may sometimes do this to allow a good spot for a debug marker, but unless it's complicated like dimitris example below, I'll use the more concise (and readable IMO) version in final code Commented Dec 19, 2012 at 17:00

3 Answers 3


This is not a php-only issue, therefore there might be potential duplicate questions. Generally

The first approach (return count(...)) is faster to read and in some cases will produce faster code, because of the time consumed to instantiate the variable $count.

The second approach is kind of easier to debug and maintain. Each operations takes place in a distinct line, which is easier to isolate hence debug, since some IDEs can place a debug breakpoint to the exact line. It is also easier to maintain/extend in case you want for example to log the result or do another operation with this.

I do not believe there is a "better" way, or that it matters so much for a one/two liner. I would use the first one and then refactor it in case it had to be extended.

What many people would agree upon is that something like:

log("$array"); return count($array) * 4 - ($array4==null)?(count($array2)^94):int_val($xyz);

should better be broken into different lines.


Don't worry about performance in this case - this kind of micro-optimization is meaningless, useless, and in short, a waste of time.

The only scenario where one would introduce temporary variables for performance reasons is when the result of a nontrivial calculation is used several times, and you want to avoid performing the calculation repeatedly. For example, in the following code:

for ($i = 0; $i < strlen($label); ++$i) {
    print $label[$i] . "; ";

...strlen($label) gets executed on every iteration, which is kind of wasteful, horribly so if your string is very long. In this situation, it pays off to precalculate the string length and store it in a variable:

$len = strlen($label);
for ($i = 0; $i < $len; ++$i) {
    print $label[$i] . "; ";

So much for performance.

In a real-world situation, however, the first thing you want to optimize for is not performance, but maintainability, in this case in the form of readability. Depending on the situation, the introduction of intermediate variables can greatly enhance readability, and it is not unusual to find, after splitting up complex computations using this technique, that the code in question can be simplified a lot, making it both easier to read and more efficient.


I think the second option is by far the better way to go, looking at the function you have it's simplistic to say the first option is harmless. But, consider a situation when you really don't know if the variable you are returning actually contains values. Let's assume you were using a more strongly typed language, where you cannot for example return a variable that is not set

function returnInt($x) {
    //some calculation to get y
    return $y;

Will most definitely throw an error (notice) if x is not set. You should check for the validity of the variable you are returning, and it will always look messing if you do that using a single line of code (look at Dimitris's example). KISS

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.