Why should I fix E_NOTICE errors?

As a developer, I work with E_NOTICE turned on. Recently though, I was asked why E_NOTICE errors should be fixed. The only reason that I could come up with was that it is best practice to correct those problems.

Does anyone else have any reasons to justif开发者_StackOverflowy the extra time/cost spent to correct these problems?

More specifically, why should a manager spend the money to have these fixed if the code already works?

SUMMARY

The PHP Runtime Configuration Docs give you some idea why:

Enabling E_NOTICE during development has some benefits.

For debugging purposes: NOTICE messages will warn you about possible bugs in your code. For example, use of unassigned values is warned. It is extremely useful to find typos and to save time for debugging.

NOTICE messages will warn you about bad style. For example, $arr[item] is better to be written as $arr['item'] since PHP tries to treat "item" as constant. If it is not a constant, PHP assumes it is a string index for the array.

Here's a more detailed explanation of each...

1. TO DETECT TYPOS

The main cause of E_NOTICE errors is typos.

Example - notice.php

<?php
$username = 'joe';        // in real life this would be from $_SESSION

// and then much further down in the code...

if ($usernmae) {            // typo, $usernmae expands to null
    echo "Logged in";
}
else {
    echo "Please log in...";
}
?>

Output without E_NOTICE

Please log in...

Wrong! You didn't mean that!

Output with E_NOTICE

Notice: Undefined variable: usernmae in /home/user/notice.php on line 3
Please log in...

In PHP, a variable that doesn't exist will return null rather than causing an error, and that could cause code to behave differently than expected, so it's best to heed E_NOTICE warnings.

2. TO DETECT AMBIGUOUS ARRAY INDEXES

It also warns you about array indexes that might change on you, e.g.

Example - code looks like this today

<?php

$arr = array();
$arr['username'] = 'fred';

// then further down

echo $arr[username];
?>

Output without E_NOTICE

fred

Example - tomorrow you include a library

<?php
// tomorrow someone adds this
include_once('somelib.php');

$arr = array();
$arr['username'] = 'fred';

// then further down

echo $arr[username];
?>

and the library does something like this:

<?php
define("username", "Mary");
?>

New output

Empty, because now it expands to:

echo $arr["Mary"];

and there is no key Mary in $arr.

Output with E_NOTICE

If only the programmer had E_NOTICE on, PHP would have printed an error message:

Notice: Use of undefined constant username - assumed 'username' in /home/user/example2.php on line 8
fred

3. THE BEST REASON

If you don't fix all the E_NOTICE errors that you think aren't errors, you will probably grow complacent, and start ignoring the messages, and then one day when a real error happens, you won't notice it.

Because an E_NOTICE indicates an error.
PHP is just too forgiving to call it that.

For example, accessing an undefined variable produces an E_NOTICE.
If this happens often, for example because you're not initializing your variables correctly, and your app is throwing notices all over the place, how are you going to tell the difference between a "variable that works just fine uninitialized" and times when you have really fat-fingered a variable name?

This may trigger a notice but will work as intended, so you ignore the notice:

if ($_GET['foo']) ...

This, on the other hand, will waste half your day while you ignore the notice and are trying to figure out why your "bar() function doesn't work":

$foo = bar();
if ($too) ...

If you don't "fix" the former case, where the variable may legitimately not exist, you can't meaningfully use notices to catch the typo in the second case.

Notices are there to help you debug your app. If you ignore them, you're only making your own life more difficult.

This kind of errors are good practice to fix, as they are what we call "code smell" they hint of another problem (like mistyped variable names or usage of undefined variables/wrong usage of methods) , or they will probably cause bugs down the road when you reflector/expand the system.
Of course, what I said here is not true 100% of the cases.

Ben I think this is an excellent question. True, it is a good practice to follow to attempt to correct any and all errors, even non-fatal ones, unless doing to would impede the designed (and thus desired) functionality of the system. Moreover, any level of error indicates that either:

a) There is something wrong with your code, or, b) You have written code that is deprecated, or have written code that is otherwise unstable and thus prone to side effects.

Therefore, I believe that if the timeline and budget of a project allows you to do so, you should always strive to correct as many errors as possible, even if they are minor in terms of their impact on the final product.

Of course, there is a certain level of risk acceptance involved in cost-benefit analysis, so it may very well be the case that the managers overseeing the outcome of the project are willing to hedge the potential future cost of fixing a known issue against the present time and cost savings associate with not fixing an error. The math basically works out the way you think it would: If the PV of the cost of fixing the error in the future is less than the money saved today by not fixing the error, then you should not fix it. On the other hand, if the PV of the cost of fixing the error in the future is greater than the money saved today by not fixing it, then you should fix it today.

That, really, is the justification for (or against) fixing an error today, regardless of the error level.

Often they're indicative of logic errors or typos. They'll help you spot situations where you've mistyped a variable name or are trying to use a variable before it's been set.

I've also seen arguments that it's more efficient to avoid errors