2013-05-14 44 views
0

背景披露: 我一直在努力研究PHP项目一段时间,但直到最近才开始认真查找最佳实践,oop设计模式,新的php版本功能等等。我应该总是在PHP中检查函数的参数吗?

很多我的代码最终看起来像这样:

public function($arg1 = 'default', $arg2 = false) 
{ 
    if(!empty($arg2) && $arg1 != 'default) { 
    // do something here 
    } 
} 

几乎所有我在github上和诸如此类的东西看到正确的OOP代码从不检查所使用的参数的存在或正确的类型。

我的问题是:是否认为总是对参数进行冗余检查或仅在特殊情况下可能发生某些错误(tm)时才是一种很好的做法。

例如,运行SQL查询并在获取结果后,我总是做 if(!empty($results)) //go do stuff

我应该这样做呢?我是偏执狂吗?

+1

我认为这是一种不好的做法,总是做任何事情 – 2013-05-14 20:26:15

+0

我总是检查,但离最佳实践还很遥远; p,它没有受伤,并且会使得处理错误变得更容易 –

+1

更好的做法的开始将是_not_给予默认情况下,如果你不想这些默认值,那么当人们使用错误的代码时,会出现一个很好的E_NOTICE错误,甚至可以记录这些错误,以确定事后发生错误的位置。不要为我隐瞒这些错误...验证论证的内容取决于个案的基础,这通常与潜在的破坏性或破坏性会产生错误的价值有关。没有SQL查询的结果不是错误,而是我书中的有效结果。 – Wrikken

回答

1

这是很好的做法先定义函数应该做什么并做适当的异常处理。

示例 - 如果我正在编写一个应用程序,该应用程序使用我的一个库,那么应用程序应该执行一些检查或库应该。

我通常选择在应用程序中进行适当的检查,以便我可以正确地通知用户。这也减轻了在图书馆做这件事的负担,并使其更加灵活。但如果你选择这样做,你应该确保以类似的方式编写所有的库和应用程序(因此是“标准”),否则它会变得混乱。

我认为github上的大部分内容都将采用库方法,因此希望您在应用程序中执行一些操作。

+1

我认为提及适当的异常处理很重要。其全部关于您的应用如何应对这些潜在的失败。 – ficuscr

+0

换句话说,保持if,并添加一个其他抛出新的异常? – Carvefx

+1

@Carvefx有一点细微差别。让事情“起泡”的概念。我会阅读一些教程,或者查看github上其他项目的源代码。编写测试可能是另一种解决这个问题的好方法。基本上以各种方式尝试和打破事情,应用程序是否以你想要的方式做出反应? – ficuscr

2

带班,你可以检查ARGS很容易通过typehint

public function doSomething(My\Super\Cl $cl, array $params){ 
... 
} 

有时你可以通过func_num_args

我同意检查参数表是很好的做法,我的意思是,它被称为Design by contract

相关问题