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.

  • 21
    Because this is forbidden on almost all other languages. And with good reason. – BoltClock Feb 1 '12 at 19:13
  • 9
    "A 'Check Engine' light? Who needs that?! Either I'm able to drive my car or I'm not!" – user11946 Feb 1 '12 at 19:13
  • 4
    O(1)...not O(n) – thetaiko Feb 1 '12 at 19:14
  • 9
    Is there any language you used where this is allowed? Even javascript does not allow it. I think you should avoid turning off your errors especially in a dev environment. Its like seeing smoke coming out of the kitchen and you spray febreeze to cover the smell – Ibu Feb 1 '12 at 19:16
  • 1
    @skcin7 - "Why is here a high-pitched beeping noise coming from the ceiling?! I'm getting tired of hearing it while stuffing blankets along the bottom of the bedroom door so that this blasted smoke stops pouring in!" – user11946 Feb 1 '12 at 20:38

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.

  • 1
    Thank you for answering my question nicely. Everyone else seemed like I committed programmer blasphemy. To somebody less experienced it does seem like it would be nice to be able to create variables on the fly however after reading the replies to my thread I can see the advantages of not doing so. This is the best answer so far. – skcin7 Feb 1 '12 at 20:36

It promotes clean coding. If you get yourself into the habit of writing your apps to be free of warnings, then you can leave warnings on, and when they occur, they'll actually tell you something meaningful. For example, subtle spelling errors like the following may be incredibly difficult to track down if you're ignoring warnings:

if ($some_variabel == 45) { ... }

However if you do this and leave warnings on:

$some_variable = 0;
if ($some_variabel == 45) { ... }

Then the bug becomes immediately evident.

  • 6
    And about the warnings, it's always better to code with FULL ERROR REPORTING and make sure nothing happens, than hide everything and try to debug blindly. I have a catalog engine here with basket and POS solution that they developped with errors turned off, you can't imagine the number of notices that appear when we turn them on. It's sickening to look at the output... so please enfore better coding practice ALWAYS... – Mathieu Dumoulin Feb 1 '12 at 19:25
  • 1
    This is so true - I'm working on a project now that is FULL of these kinds of problems. They've tripped up the system so many times it isn't funny. – Jarrod Nettles Feb 1 '12 at 20:28
  • I also have it set to error_reporting(E_ALL) when developing and I switch it to error_reporting(0) for testing and production. – skcin7 Feb 1 '12 at 20:38
  • 1
    Yes, because we all know that once you've completed a round of tests on a piece of code, that code will forever be error free and neither the requirements surrounding the larger project in which the code is embedded nor the possible structure of the input fed into the code (if any) will ever change. – user11946 Feb 1 '12 at 20:57

You should not be coding in such a way that you don't know if a variable is set.

Doing so places your code into an ambiguous state. The end result of that is typically buggy, difficult to maintain spaghetti code.

In PHP, the main ways this situation occurs is if one is having PHP automatically create global variables from the GET/POST variables (register_globals), or one is doing too much in the global scope rather than inside functions and methods. The former is a bad idea for a variety of security reasons, and the latter, for all but trivial applications, means the code probably isn't structured well.

To get around this,

  • don't use register_globals,
  • specifically initialze every global,
  • don't do a lot in the global scope,
  • don't use include() as a replacement for proper function and method calls.
  • Undefined variables are not ambiguous. They are "undefined", and the language has very precise rules how undefined values are coerced to other types. – tdammers Feb 1 '12 at 20:37
  • 3
    Re-read what I wrote, please. The variable isnt ambiguous. The code is. How can you end up in a situation where the code doesnt know if a variable is set? The only way that happens is if you are doing what I describe above. – GrandmasterB Feb 1 '12 at 20:41

Like BoltClock and JackManey said in the first few comments, it is indeed important to declare all your variables even if something seems to work. One day, you'll run into an issue where you used two times a variables that you expected NOT to be initialized and then it'll fail.

You will then lose 2-3 hours tracing and debugging trying to find out why you are getting this funky behavior and then realize, omg, i will always initialize my variables from now on. It will prevent me from getting that one funky error.

And if you get into another language you will most probably have to do so anyway. So take the time to initialize your variables, it will save you LOTS of trouble later.

  • 3
    It will save anyone coming in to look at your code a lot of trouble later, too. – thetaiko Feb 1 '12 at 19:21

Notices are not errors. They are debug messages. And PHP allows to use variables sans initialization. It is not a compiled language, and it does correctly substitute absent variables for NULL. It just gives you an additional debugging aid. It's often just in case, but oftentimes useful.

People supress notices with isset or @ and error_reporting when it becomes too overwhelming. And you do really need to differentiate between useful and pointless notices. It does not make sense to keep them everywhere, and it likewise doesn't make sense to suppress them everywhere. (Even seasoned PHP coders are overwhelmed with that differentiation.)

  • The non-compiled is not true, PHP is compiled to an OPCode or intermediary code just like many other languages (Ms.Net, Java, etc) but doesn't use common "linkage" and "memory allocations" that we are used to. Z_Data structure is what is used in Zend Engine to support on the fly data creation and that is why there is no typing per se. It is then wrong to say that php is not compiled because it doesn't require definition of the the variablles... The rest is good work :) – Mathieu Dumoulin Feb 1 '12 at 20:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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