4

给我一个很好的理由这样做

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

而不是这个

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

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

不欢迎以下原因：

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

3 回答 3

5

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

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

if( @IsAvailable() ) {

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

于 2013-02-22T15:32:09.747 回答
1

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

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

于 2013-02-22T15:26:59.517 回答
0

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

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

好消息是，从 PHP 7 开始，我们可以使用更好的方式，null-coalescence operator ?? 像这样工作：

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

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

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

现在你可以使用

$result = $value ?? $anotherValue;
于 2016-02-23T13:59:40.110 回答