I recently turned all possible error-messages on with error_reporting(-1);, on my PHP project. Of course, right away I got alot of messages. For example:

Notice: Undefined variable: foo in /.../file.php on line 205

So I started updating my code to get rid of all the notices. Mostly, by adding isset($foo) and making the $foo = NULL;

So, I'm wondering. How important are these notices really? I mean, if the $foo variable is not set, then it should be false/null/not-set by default..so technically the code works?!

If I would get rid of all notices, then does it make the process faster or slow it down (because I'm adding more code, isset($foo), $foo = NULL etc)? How do you guys deal with these notices, or do you even pay attention to them?
I guess, the most important question is: Should the code be written so strict, that it would never generate any notices or warnings?


If it does not have any effect on the functionality of your code, now or in the future, then don't waste your time.

If the particular "offending" line of code does not cause any actual problems then what is your incentive to "fix" it? You are not solving any problems, you are just satisfying an overzealous interpreter.

Conversely, if the line generating the warning is resulting in some undesired operations or affects the status of a method, by all means fix it.

  • 1
    Agreed. However, to get really deep: Wouldn't strict code mean better performance and more server-friendliness? The reason why I'm optimizing this much, is that the project is going to be a commercial release. And I cannot control the server setup. And most of all, I'm worried, that my coding style is incorrect and non-standard. That I should be using methods as standard, that would prevent notices..? Thanks for answering:) – Kalle H. Väravas Aug 30 '11 at 23:05
  • 2
    @Kalle Honestly, a warning like that likely indicates (and don't take offense to this) a less than ideal implementation. If it isn't initialized, it isn't being used. If it isn't being used, why put it where it is at all? That said, it is something to look for, but I honestly don't know the situation so it very well may be something that isn't even a bother. – Glenn Nelson Aug 30 '11 at 23:14
  • @Kalle Regarding "Wouldn't strict code mean better performance and more server-friendliness?" - In this situation, adding a lot of checking code that probably doesn't need to be there will put you in the opposite direction. Why waste CPU cycles performing operations that are not required in any way? – Glenn Nelson Aug 30 '11 at 23:18
  • Ok you gave me alot to think about. I found solutions to most of the notices, by optimizing the code. And I used twice $foo = $bar = NULL;. Basically got rid of ~130 messages like that. I wont follow the notice messages so strict. But it seems, that notice messages are nice pointers to not-so-much-optimized-code.. I think this is a nice conclusion to this question:) – Kalle H. Väravas Aug 31 '11 at 1:22
  • 4
    -1: such approach leads to PHP being know for low code quality. – vartec Aug 31 '11 at 10:41

The notices are there to draw attention to things that might be problems. For example, a lot of bugs can come from typos: if the variable name is $filename and I type $filenaem, some languages will catch that, but in PHP, it's valid. So the notices can be useful in those cases.

Using the notices to flag potential errors as you write code the first time can be a very useful process; suddenly turning up the warning level in an existing codebase often results in a ton of useless warnings.

Whether the code should be edited to remove all warnings and notices is a cost-benefit analysis: is it worth the time for the problems it may solve? You have to answer that on a case-by-case basis.

  • That's what I did, turned up all messages on 6 month old project. The most weirdest message was, that defined variable needed to be inside quotes in $_SESSION. So my current $_SESSION[PREFIX . 'foo'] was incorrect and $_SESSION['PREFIX' . 'foo'] or even 'PREFIXfoo' IS correct. That's extremely confusing later and weirdest part is that echo PREFIX . 'foo'; is absolutely correct.. Am I missing something? – Kalle H. Väravas Aug 30 '11 at 23:12
  • 1
    echo PREFIX . 'foo'; is only correct if PREFIX has been defined as a constant - otherwise it will still assume it is an undefined constant and then cast it to a string... – HorusKol Aug 30 '11 at 23:27

Cleaning up some notices can potentially thwart a bug. Undefined variables, for example, can result in errors if you try to read the variable that wasn't initialized. Whenever possible, I try to write warning and notice free code. But, if I am using somebody else's code, I don't generally take the time to clean up their errors or notices.

  • Agreed. However, since this project is CMS software and it is going to be a valuable base for projects in the future. So it seems very logical to make it as close to standard as inhumanly possible. Fixing the core related notices is not hard (read: already fixed.) But, huge classes are more complex, because of the functions looping order is criss-crossed. – Kalle H. Väravas Aug 30 '11 at 23:27

My general approach take is to enable notices on development machine and disable them on live servers. Assuming that you do not know, php 5 has a new error level E_STRICT. As for fixing the notice messages: It is up to you. You cannot know if a notice message will cause an error unless you look at the code. If you are taking time to look up the code, you might as well fix them.

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.