Something is wrong with ignoring return value from function in PHP

Question

For example:

// somefile.php function doSomething() { // do lots of code, whatever... return $something; } // mainfile.php include "somefile.php" doSomething(); // ignored the return value, we don't need it here 

What happens when a function in PHP returns a value, but we don’t care about that? Is there something wrong with this behavior, or should we always get a variable, even if we never use it outside the scope? How does PHP manage resources by returning a value that will not be used outside the scope?

Answer 1

The return value is discarded. There is nothing wrong with that. Even functions without an explicit return implicitly return null :

 function foo() {} var_dump(foo()); // NULL 

Answer 2

For me, it all comes down to a simple paradigm:

"A function should do one thing: it should do it well, it should only do it."

If you have more than one reason to call this function, it does a lot.

---

From a language point of view, there is absolutely no problem ignoring return values. From a clean point of the code is.

The A insert() function should insert the record into the database. Do not return the ID of the inserted record. You did not ask for it.

A setLatitude() should change the internal state of objects without loading your class timezone and a digit in which the timezone, which is latitude, and they write it to the database. (Saving an object can do this).

---

If you have two reasons for calling a function, it serves several purposes, and from a pure point of view of the code, therefore: “Too much”

Of course, there may be cases where this may make sense, but since a general rule that does not take into account the return values ​​may be a smell of code.

Answer 3

This smell of code, every time you return something that will not be used, means that you have no idea about your audience - maybe you are missing some other concept.

In addition, such functions usually suffer from the separation of command requests .

A few examples :

• array_unshift(&$arr, $value, ...) Adds the passed values ​​to the array and returns the new size of the array, how often do you want this information? and if you do, you can always call count($array) , which was designed for this purpose.

• sort(&$arr) sorts the passed array and returns if it was successful. does that make sense? when something happened wrong, you need to know the exception should be raised / caused by an error, do you really want to check success all the time? and you?

• print_r() is an example of this, it returns true (always so useless anyway) or a string, depending on the arguments you pass to it. this is definitely not what the api should look like.

One possible exception may be a free interface such as jQuery, but this is a VERY specific case.

TIP . Write some tests and rethink your architecture, if that really doesn't make sense in any other way, it's probably good enough. But you should always be careful in such situations.

Answer 4

There is nothing wrong. If you have a function that returns a value, but also somehow changes the state of the program (called a side effect ), calling the function, but ignoring the return value will just cause all the side effects applied. Of course, you cannot use the return value if you do not store it, but sometimes all you need is side effects of the call.

There are some people who believe in designing the API in such a way that the functions that cause their side effects (commands) and the functions that are called to monitor some state of the program (requests) are separated as much as possible. This principle is called Separation of request commands . The idea is that all functions that return something should not change the state of the program, because they observe it, and the act of observation should not affect the observed state. All functions that return nothing are then treated as commands called solely for their side effects.

Therefore, people who follow these principles might think that since your function explicitly applies a side effect (or why do you call it and don't care about the return value?), It should not observe any state (have a return value). Please note, however, that this principle should not always be respected in the letter, and there is not much agreement on it.

Why are some proponents of requesting a team request? Because it ensures that consecutive requests return the same response if no command was applied between requests. This is a kind of weaker form of immutability and bears a weakened form of advantages that immutability can have for reasoning about the logic of a program. In a sequential application, objects are immutable between commands.

In my opinion, maintaining this principle often leads to less confusing APIs and clearer programming logic, but it cannot be carried too far. There are times when you may need to apply a side effect and return a value. However, when the return value is only a success value, consider throwing an exception on error.

Answer 5

Return is simply a means of passing a variable from a function used outside the function. Variables inside the function are destroyed if they are not set to static. To save this value, you must assign a variable to save it.

Very often for the code there is no need to return a variable. The fact that there is no need for the returned variable does not mean that there is nothing to use for the returned variable.

Although allowing the return of a function or method to die off does not have harmful consequences, it is usually bad practice. When a developer creates a refund, he has a reason. This reason can be several things, such as: the effect of the function cannot have a result other than return (this example is unlikely to fit into your case), the return result can be a link for sequential operations, the return result can be for debugging.

I recommend that you find a goal for the return result and process it accordingly. Often, ignoring the return result can potentially lead to an unpredictable state in your application that could have been prevented.

For example, array_walk (). It processes your array by reference, there is no need to store the returned variable for standard execution, assuming everything is going well; however, if it fails, you have no way to find out, and your application may fail or give unexpected results if you automatically assume that this did not work. If you collected this return variable and saw that it was false, you could throw an exception, try to find out the reason and try again or register the exception for future reference.