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. – user7007 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? – user7007 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.

  • So you're happy with the php engine checking if it should verbose an error 1000 times in a single page load? Because that won't slow down your app right.... – zanderwar Aug 30 at 23:11

My point of view is, if you see a notice... you should without a doubt and without hesitation; fix it.

Not only does an entire error/notice free app make you a better coder, impress your boss, and scale you up in the employment industry, but it is in fact (while the difference is negligible) an optimization...

$a = [1,2,3,4,5];

// check speed of: no notices
$start = microtime(true);
for ($i = 0; $i < 10000; $i++) {
    $key = rand(0, 4);


$resultA = microtime(true) - $start;

// check speed of: notices
$start = microtime(true);
for ($i = 0; $i < 10000; $i++) {
    $key = rand(5, 10);


$resultB = microtime(true) - $start;

// check speed of: notice prevention
$start = microtime(true);
for ($i = 0; $i < 10000; $i++) {
    $key = rand(5, 10);

    if (isset($a[$key])) {};

$resultC = microtime(true) - $start;

ini_set('error_reporting', 'E_ALL & ~E_NOTICE');

// check speed of: notices with notices disabled
$start = microtime(true);
for ($i = 0; $i < 10000; $i++) {
    $key = rand(5, 10);


$resultD = microtime(true) - $start;

echo 'No notices: ' . $resultA . PHP_EOL;
echo 'Notices: ' . $resultB . PHP_EOL;
echo 'Notice prevention: ' . $resultC . PHP_EOL;
echo 'Notices (with notices disabled via INI): ' . $resultD;

// PHP 7.3
// No notices: 0.00071501731872559 
// Notices: 3.8168609142303 
// Notice prevention: 0.0005791187286377
// Notices (again but with notices disabled via INI): 0.0047409534454346

As you can see even with notices disabled; an overhead is applied since the PHP engine has to check whether or not it should verbose it's concern. Also notice that even with an isset($a[$key]) call; the result is significantly faster.

While 95% of notices may be harmless, 5% of those give you an indication of a very real problem that could spread like a plague throughout database relationships and more.

Anyone who believes it's ok to ignore notices, or worse hide them on development; wouldn't be someone I'd personally hire.

protected by gnat Aug 31 at 13:22

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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