在php中使用isset()而不是@有什么重要的原因吗 [英] Are there any essential reasons to use isset() over @ in php

查看:29
本文介绍了在php中使用isset()而不是@有什么重要的原因吗的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

So I'm working on cleanup of a horrible codebase, and I'm slowly moving to full error reporting.

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

It's an arduous process, with hundreds of notices along the lines of:

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

由于使用变量,假设未定义的变量只会处理为 false,例如:

due to uses of variables assuming undefined variables will just process as false, like:

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

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

The goal is to be able to know when a incorrectly undefined variable introduced, the ability to use strict error/notice checking, as the first stage in a refactoring process that -will- eventually include rewriting of the spots of code that rely on standard input arrays in this way. There are two ways that I know of to replace a variable that may or may not be defined in a way that suppresses notices if it isn't yet defined.

仅替换像 $_REQUEST['incoming'] 这样只用

It is rather clean to just replace instances of a variable like $_REQUEST['incoming'] that are only looking for truthy values with

@$_REQUEST['incoming'].

用标准"测试替换像 $_REQUEST['incoming'] 这样的变量的实例是很脏的,也就是

It is quite dirty to replace instances of a variable like $_REQUEST['incoming'] with the "standard" test, which is

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

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

And you're adding a ternary/inline if, which is problematic because you can actually nest parens differently in complex code and totaly change the behavior.

所以.... ...与使用 (isset($something)? $something : null)<相比,使用 @ 错误抑制符号是否有任何不可接受的方面/代码> ?

So.... ...is there any unacceptable aspect to use of the @ error suppression symbol compared to using (isset($something)? $something : null) ?

为了尽可能清楚,我没有将重写代码使其更好"与@"进行比较,这是由于实际重构增加了复杂性,这是此过程的后期阶段.我只是比较了我所知道的将 $undefined_variable 替换为不引发通知的版本的两种方式(可能还有其他方式).

To be as clear as possible, I'm not comparing "rewriting the code to be good" to "@", that's a stage later in this process due to the added complexity of real refactoring. I'm only comparing the two ways (there may be others) that I know of to replace $undefined_variable with a non-notice-throwing version, for now.

推荐答案

另一种似乎适用于到处使用超全局变量"的蹩脚代码的选项是将全局变量包装在专用的数组对象中,并使用更多或不太明智的 [] 行为:

Another option, which seems to work well with lame code that uses "superglobals" all over the place, is to wrap the globals in dedicated array objects, with more or less sensible [] behaviour:

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"和朋友,并可以观察其余代码如何使用它们.

This way you get back control over "$REQUEST" and friends, and can watch how the rest of code uses them.

这篇关于在php中使用isset()而不是@有什么重要的原因吗的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆