Question

作为开发人员，我开启了E_NOTICE。最近，我被问到为什么应该修复E_NOTICE错误。我能提出的唯一理由是纠正这些问题是最佳做法。

是否有其他人有理由证明纠正这些问题需要额外的时间/成本？

更具体地说，如果代码已经有效，为什么经理会花钱来修复这些？

Answer 1

<强>概要

在开发过程中启用E_NOTICE有一些好处。

出于调试目的：NOTICE消息将警告您代码中可能存在的错误。例如，警告使用未分配的值。找到拼写错误并节省调试时间非常有用。

注意消息会警告您样式不好。例如，$ arr [item]最好写成$ arr ['item']，因为PHP试图将“item”视为常量。如果它不是常量，PHP假定它是数组的字符串索引。

以下是对每个......的详细解释。

<强> 1。检测TYPOS

E_NOTICE错误的主要原因是拼写错误。

示例 - 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...";
}
?>

没有E_NOTICE的输出

Please log in...

错误！你不是那个意思！

使用E_NOTICE输出

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

在PHP中，不存在的变量将返回null而不是导致错误，这可能导致代码的行为与预期不同，因此最好注意E_NOTICE警告。

<强> 2。检测AMBIGUOUS ARRAY指数

它还会警告您可能会改变的数组索引，例如

示例 - 代码今天看起来像这样

<?php

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

// then further down

echo $arr[username];
?>

没有E_NOTICE的输出

fred

示例 - 明天您包含一个库

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

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

// then further down

echo $arr[username];
?>

，图书馆会这样做：

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

新输出

清空，因为现在它扩展为：

echo $arr["Mary"];

并且Mary中没有键$arr。

使用E_NOTICE输出

如果只有程序员打开E_NOTICE，PHP就会打印一条错误消息：

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

第3。最好的理由

如果你没有修复你认为不是错误的所有E_NOTICE错误，你可能会变得自满，并开始忽略这些消息，然后有一天当真正的错误发生时，你就赢了“注意它。

Answer 2

因为E_NOTICE表示错误 PHP太过于宽容而无法称之为。

例如，访问未定义的变量会产生E_NOTICE 如果这种情况经常发生，例如因为您没有正确初始化变量，并且您的应用程序在整个地方都会发出通知，那么您将如何区分“未正常运行的变量”和你真的胖了一个变量名吗？

这可能触发通知但会按预期工作，因此您忽略了通知：

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

另一方面，如果您忽略通知并且试图找出“bar()功能不起作用”的原因，这将浪费您一半的时间：

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

如果你没有“修复”前一种情况，即变量可能合法地不存在，你就不能有意义地使用通知来捕捉第二种情况中的拼写错误。

通知可以帮助您调试应用。如果你忽视它们，那你只会让自己的生活变得更加困难。

Answer 3

这种错误是修复的好习惯，因为它们是我们所谓的“代码味道”，它们暗示了另一个问题（如错误的变量名称或未定义变量的使用/方法的错误使用），或者它们可能会导致反射/扩展系统时，路面会出现问题当然，我在这里说的不是100％的案例。

Answer 4

Ben我认为这是一个很好的问题。确实，遵循尝试纠正任何和所有错误（即使是非致命错误）是一个好习惯，除非这样做会妨碍系统的设计（并因此需要）功能。此外，任何级别的错误都表示：

a）您的代码有问题，或者， b）您编写的代码已被弃用，或者编写的代码不稳定，因此容易产生副作用。

因此，我认为如果项目的时间表和预算允许您这样做，您应该始终努力纠正尽可能多的错误，即使它们对最终产品的影响很小。 / p>

当然，成本效益分析中存在一定程度的风险接受度，因此监督项目结果的管理人员很可能会对未来修复已知成本的风险进行对冲。与不修复错误相关联的当前时间和成本节省问题。数学基本上按照你认为的方式运行：如果未来修复错误的成本PV低于今天通过不修复错误而节省的金额，那么你就不应该修复它。另一方面，如果未来修复错误的成本的PV大于今天通过不修复它而节省的费用，那么你今天应该修复它。

这确实是今天修复错误的理由（或反对），无论错误级别如何。

Answer 5

通常它们表示逻辑错误或拼写错误。它们可以帮助您发现错误输入变量名称或在设置之前尝试使用变量的情况。

我也看到了it's more efficient to avoid errors

的论点

我为什么要修复E_NOTICE错误？

5 个答案: