在php中使用@isset（）有什么必要的原因吗

所以我正在清理一个可怕的代码库，我正在慢慢地转向完整的错误报告

这是一个艰难的过程，有数百条通知，内容大致如下：

Notice: Undefined index: incoming in /path/to/code/somescript.php on line 18

由于使用变量，假设未定义的变量将作为false处理，例如：

if($_SESSION['incoming']){
    // do something
}

我们的目标是能够知道何时引入了一个不正确的未定义变量，能够使用严格的错误/通知检查，作为重构过程的第一阶段，最终将包括以这种方式重写依赖于标准输入数组的代码点。我知道有两种方法可以替换可能定义或可能未定义的变量 如果尚未定义，则以抑制通知的方式

只替换像

$\u REQUEST['incoming']

这样的变量的实例是相当干净的，它只查找具有

@$_REQUEST['incoming'].

用“标准”测试替换变量的实例（如

$\u REQUEST['incoming']

）是非常糟糕的，因为“标准”测试是

(isset($_REQUEST['incoming'])? $_REQUEST['incoming'] : null)

您正在添加一个三元/内联if，这是有问题的，因为您实际上可以在复杂代码中以不同的方式嵌套paren，并完全改变行为

所以。。。与使用

（isset（$something）？$something:null）

相比，使用

@

错误抑制符号是否有任何不可接受的方面

---

编辑：尽可能清楚地说，我并不是将“将代码重写为良好”与“@”相比较，这是这个过程中的一个后期阶段，因为实际重构的复杂性增加了。目前，我只是比较我所知道的用非通知版本替换$undefined_变量的两种方法（可能还有其他方法）。

您回答了自己的问题。它会抑制错误，不会调试它。

在我看来，您应该使用

isset（）

方法正确检查变量

抑制错误并不会使它消失，它只是阻止它显示，因为它本质上说是“为此行设置

error\u reporting（0）

”，如果我没记错的话，它也会比检查

isset（）

慢

如果您不喜欢三元运算符，那么应该使用完整的if-else语句。

---

这可能会使您的代码更长，但更具可读性。

我永远不会抑制开发服务器上的错误，但我自然会抑制实时服务器上的错误。如果您是在实时服务器上开发，那么，您不应该这样做。这对我来说意味着

@

符号总是不可接受的。没有理由抑制开发中的错误。您应该看到所有错误，包括通知

@

也会使速度减慢一点，但我不确定

isset（）

是快还是慢

如果多次编写

isset（）

对您来说是一件痛苦的事情，我只需要编写一个函数，如

function request($arg, $default = null) {
   return isset($_REQUEST[$arg]) ? trim($_REQUEST[$arg]) : $default;
}

---

只需使用

request（'var'）

。

您需要自行决定是否可以接受

@

使用。这很难从第三方获得评级，因为我们需要知道这方面的代码

但是，看起来您不希望任何错误抑制让您作为需要使用它的程序员更容易访问代码

您可以在对所引用的代码库进行重新分解时创建它的规范，然后将其应用于代码库

这是你的决定，使用语言作为工具

---

您也可以通过使用own或使用or via来禁用错误抑制运算符。

另一个选项（似乎适用于到处使用“超全局”的lame代码）是将全局对象包装在专用数组对象中，具有或多或少合理的[]行为：

class _myArray implements ArrayAccess, Countable, IteratorAggregate
{
     function __construct($a) {
       $this->a = $a;
     }

    // do your SPL homework here: offsetExists, offsetSet etc

    function offsetGet($k) { 
        return isset($this->a[$k]) ? $this->a[$k] : null;
        // and maybe log it or whatever
    }
}

然后

 $_REQUEST = new _myArray($_REQUEST);

---

这样，你就可以控制“$请求”和朋友，并且可以观察其他代码是如何使用它们的。

我实际上发现了另一个警告，这里所提到的超出了我必须考虑的，也就是说，在处理函数或对象方法调用时，@甚至可以通过错误终止脚本来防止错误，如下所示：

这是一个非常有力的论据，在罕见的情况下，禁止变量通知的尝试反而抑制了函数未定义的错误（可能会蔓延到更严重的错误中，这是人们不喜欢@的另一个未公开的原因。）

大多数所谓的“PHP程序员”根本不理解分配变量的整个想法。
只是因为缺乏任何编程教育或背景

好吧，它和普通的php脚本没什么大不了的，php脚本是经过大量努力编写的，由一些HTML/Mysql意大利面条和很少的变量组成

另一个问题是更大的代码，编写起来相对容易，但调试却成了一场噩梦。当你明白错误信息是你的朋友，而不是一些恼人和令人不安的事情，最好是闭嘴，你就要学会珍惜每一条血腥的错误信息

因此，基于这种理解，您将学会在代码中不留下任何故意错误。
并定义所有变量。
这样，你的朋友就会收到错误消息，告诉你出了什么问题，然后通过搜索找出一些由未初始化变量引起的难以发现的错误

---

缺乏教育的另一个有趣结果是，十分之九的“PHP程序员”无法区分错误抑制和关闭显示错误，并使用前者代替后者

有史以来最具误导性的答案。“我会很自然地抑制实时服务器上的错误”，我的脚！你认为错误按摩的作用是什么？为了激怒程序员？@Col.shrapanel您真的想让用户看到“注意：第46行上的未定义索引废话？”实际上，我有一个名为in（）的函数来处理针对exactl的$_请求