php中isset的作用,是否有任何基本的理由在php中使用isset()over @

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

这是一个艰巨的过程,有数百条通知：

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

由于使用变量假设未定义的变量将只处理为false,如：

if($_SESSION['incoming']){

// do something

}

目标是能够知道何时引入了错误的未定义变量,使用严格错误/通知检查的能力,作为重构过程的第一阶段 – 最终将包括重写依赖于标准输入的代码点这样的数组.我知道有两种方法可以替换可能定义或未定义的变量

以某种方式抑制通知,如果尚未定义.

仅仅替换像$_REQUEST [‘incoming’]这样的变量实例是相当干净的,这些变量只是寻找真实值

@$_REQUEST['incoming'].

用“标准”测试替换像$_REQUEST [‘incoming’]这样的变量的实例是非常脏的,这是

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

而且你添加了一个三元/内联if,这是有问题的,因为你实际上可以在复杂的代码中以不同的方式嵌套parens并完全改变行为.

所以…….使用@错误抑制符号与使用(isset($something)相比,是否有任何不可接受的方面？$something：null)？

编辑：为了尽可能清楚,我不是将“将代码重写为好”与“@”进行比较,由于真正的重构增加了复杂性,这是此过程的后期阶段.我只是比较了我所知道的两种方式(可能还有其他方法),用现在的非通知抛出版本替换$undefined_variable.

解决方法:

另一个选项,似乎适用于在整个地方使用“超级全局”的蹩脚代码,是将全局变量包装在专用数组对象中,具有或多或少明智的[]行为：

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);

通过这种方式,您可以获得对“$REQUEST”和朋友的控制权,并可以观察其余代码如何使用它们.

标签：php,syntax,syntax-error

来源： https://codeday.me/bug/20190721/1495166.html