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 justify 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.