PHP Variables – Why Creating Variables on the Fly is Discouraged

PHPvariables

Are you guys familiar with those pesky PHP notice errors? You know, the ones that will appear when you do something like this:

if($some_variable == 45)

But if $some_variable wasn't created already, PHP will be like "Hey! Idiot! This variable wasn't defined yet!" and output a Notice Error onto the screen. However, you can simply turn PHP Notice Errors off by using error_reporting(0) and the application works perfectly. What's the point? Who cares if a variable wasn't created yet? Why can't you just create it on the fly inside the if statement? I feel like this is the easy, no-brainer way to do it, but apparently PHP discourages this practice. Why?

What I find myself having to do a lot of times is something like this:

if(isset($some_variable) && $some_variable == 45)

If $some_variable is not set, the if statement automatically fails, so the second condition of the if statement is never checked, so the Notice Error never happens. This works great, but I feel like it shouldn't be necessary. Some of the applications I am working on are huge and I fear that the extra added conditions will slow down my poor old server if there are dozens of instances of it, combined with thousands of users. I know that this is just a single extra statement which would be O(1), which isn't a lot of resources, but it's still something I worry about. Should I not worry about O(1) even if I hypothetically were to have thousands of users? Am I caring too much about being efficient?

I know PHP Notice errors can easily be turned off by using error_reporting(0). I'm not sure if certain types of errors can be turned on/off as desired because I haven't researched error_reporting() extensively.

My question is what's the point? Why is it discouraged to create variables on the fly? I feel like creating variables on the fly may be a little bit lazier but is 10000000x easier to program and should be the no-brainer encouraged way to do it.

This is meant to be both a philosophical and a technical question.

Best Answer

While sometimes I think it would be nice to be able to create variables on the fly without generating those pesky "notices", I can often see the advantages of not being able to do so.

I think the biggest benefit to explicitly declaring variables, or checking that variables are set, is code readability. The isset in your example indicates to the person reading the code that $some_variable may not be set. While this doesn't necessarily save much time (as they'll see that it isn't set when they read the notice), it provides the reader with more information, which is always beneficial.

String Concatentation

Obviously this is not a problem in PHP because there are separate string concatenation (.) and addition (+) operators.

^JavaScript

var a = 5;
var b = "10"
var incorrect = a + b; // "510"
var correct = a + Number(b); // 15

String Comparison

Often in computer systems "5" is greater than "10" because it doesn't interpret it as a number. Not so in PHP, which, even if both are strings, realizes they are numbers and removes the need for a cast):

^JavaScript

console.log("5" > "10" ? "true" : "false"); // true

^PHP

echo "5" > "10" ? "true" : "false";  // false!

Function signature typing

PHP implements a bare-bones type-checking on function signatures, but unfortunately it's so flawed it's probably rarely usable.

I thought I might be doing something wrong, but a comment on the docs confirms that built-in types other than array cannot be used in PHP function signatures - though the error message is misleading.

^PHP

function testprint(string $a) {
    echo $a;
}

$test = 5;
testprint((string)5); // "Catchable fatal error: Argument 1 passed to testprint()
                      //  must be an instance of string, string given" WTF?

And unlike any other language I know, even if you use a type it understands, null can no longer be passed to that argument (must be an instance of array, null given). How stupid.

Boolean interpretation

[Edit]: This one is new. I thought of another case, and again the logic is reversed from JavaScript.

^JavaScript

console.log("0" ? "true" : "false"); // True, as expected. Non-empty string.

^PHP

echo "0" ? "true" : "false"; // False! This one probably causes a lot of bugs.

So in conclusion, the only useful case I can think of is... (drumroll)

Type truncation

In other words, when you have a value of one type (say string) and you want to interpret it as another type (int) and you want to force it to become one of the valid set of values in that type:

$val = "test";
$val2 = "10";
$intval = (int)$val; // 0
$intval2 = (int)$val2; // 10
$boolval = (bool)$intval // false
$boolval2 = (bool)$intval2 // true
$props = (array)$myobject // associative array of $myobject's properties

I can't see what upcasting (to a type that encompasses more values) would really ever gain you.

So while I disagree with your proposed use of typing (you essentially are proposing static typing, but with the ambiguity that only if it was force-cast into a type would it throw an error — which would cause confusion), I think it's a good question, because apparently casting has very little purpose in PHP.

Best Answer

Related Solutions

Php – Why do many PHP Devs hate using isset() and/or any of PHP’s similarly defensive functions like empty()

Php – Type casting variables in PHP, what is the practical reason for doing this

String Concatentation

String Comparison

Function signature typing

Boolean interpretation

Type truncation

Related Topic