PHP @ 代替 isset 来测试 $_GET 值答案

【问题标题】：PHP @ instead of isset to test a $_GET valuePHP @ 代替 isset 来测试 $_GET 值
【发布时间】：2013-02-08 06:17:55
【问题描述】：

给我一个这样做的充分理由

if( isset($_GET['key']) && ($_GET['key'] === '123') )
{...

而不是这个

if( @$_GET['key'] === '123' )
{...

我要的是这个非常具体的代码案例，而不是一般！

不欢迎以下原因：

"使用@ 会使应用程序减慢几纳秒，因为无论如何都会创建错误（即使它被抑制）。“我更喜欢慢一点代码但更具可读性。
"使用@ 是坏习惯。" 一般情况下这可能是正确的，但我不相信这种情况（而且坏习惯可能取决于上下文，PHP 手册中的函数，如 fopen 他们建议在某些情况下使用@，请参阅错误/异常 http://www.php.net/manual/en/function.fopen.php)

【问题讨论】：

所以你认为错误抑制会让你的代码更具可读性？！？ wtf！
虽然你可以做到这一点，但为什么不直接定义一个全局 GET 函数之类的？
可恢复性。常见的isset 编组将无法确定变量是否未设置，总是默默地用替代值替换它。 @ 抑制是可逆的。如果您绝对确定以后不需要调试某些内容，请使用isset。如果输入参数可能至关重要/安全相关，请使用@（然后使用日志记录错误处理程序）。
!empty() > isset()
@MarkBaker：不，但在这种情况下是的。我明确表示不是一般情况。让我们不要为此发动战争。我渴望一个简单的理由/答案。

【解决方案1】：

想想当您的网站/应用开始每天收到数万/数十万（或更多）请求时，您的应用程序可能会减慢多少。如果您将抑制错误作为标准，则每个请求可能都有几十个 - 突然间，您的网站明显比您希望的要慢。

除此之外，您最终可能会隐藏您在开发时真正想要注意的错误。

【讨论】：

""使用 @ 将使应用程序减慢几纳秒，因为无论如何都会创建错误（即使它已被抑制）。"嗯，我更喜欢较慢的代码但更具可读性。"
你有没有分析过任何代码？您是否也只使用单引号？
"我更喜欢慢代码但更易读。"嗯...不一定是智慧之言。
@mario 我已经分析了代码，但不是专门测试@ 运算符的区别。使用单引号/双引号有什么区别？
@mario：单引号有什么问题，当我不需要为 $varibales 解析字符串时，它们不是比双引号更好的选择吗？您是否建议我应该为` === "123"` 使用双引号？

【解决方案2】：

性能影响实际上并不是反对此示例的最佳论据，您必须在自己的应用程序中测量性能以确定这是否是一个问题。如果没有设置大量要检查的项目，或者如果您在循环中放置了这样的检查，则更有可能导致速度变慢。

与使用 @ 运算符相关的主要问题是它可能会成为您代码中的约定，因此虽然您的示例可能看起来无害，但您以后可能会发现自己或您的团队正在使用：

if( @IsAvailable() ) {

错误抑制开始隐藏您没有预料到的真实错误以及您所做的错误 - 您根本不知道发生了什么，因为您根本没有收到任何异常信息。

【讨论】：

【解决方案3】：

如果你不把性能问题作为论据，那确实没问题。但它不必在所有情况下都存在，因为 @ 会抑制所有可能的错误，即使是那些你没有想到的错误。但在这种情况下，似乎没有其他错误是您想要抑制的。

我同意您的观点，即在读取值之前执行 isset() 非常难看，我也不喜欢编写它。但是 insert @ before 语句看起来很难看。它会降低较长代码的可读性。

好消息是，从 PHP 7 开始，我们可以使用更好的方法，空合并运算符 ??，其工作原理如下：

if($_GET['key'] ?? '' === '123' ) {}

它基本上是这个的替代品：

$result = isset($value) ? $value : $anotherValue;

现在你可以使用

$result = $value ?? $anotherValue;

【讨论】：