请求参数和PHPDoc的

可能重复：
Is there a standard for documenting GET/POST parameters?请求参数和PHPDoc的

试图找出通过PHPDoc的的方式，有意义的文档请求参数的最佳方式。具体来说，我有一些通过GET/POST接收参数的Zend Framework控制器操作，但不是功能参数。这有意义吗？

/** 
* Display a pagination/grid list of rows. 
* 
* @param string $_GET['order'] What field to sort on 
* @param string $_GET['dir'] Direction to sort; either ASC|DESC 
* 
* @return void 
*/ 
public function listAction() 
{ 
    $order = $this->_request->order; 
    ...

如果我生成的文档对于该方法，就不会出现的指示“命令”和“DIR”可以经由URL字符串该方法被传递。它会更有意义吗？

@param string $order

我应该使用@var吗？

思想欢迎。

来源

2009-08-12 typeoneerror

非常困惑，为什么我在“重复”之前一年问了这个问题，而我的关闭了。没有意义。 – typeoneerror 2011-05-27 16:46:03

好问题，在Kohana回答这个问题3.谢谢你的观点：] – Brenden 2012-01-17 20:03:32

我会避免使用@param。

此外，您可以使_validate（）方法使其在代码中显而易见。然后你可以使用_validate（）创建一个接缝进行单元测试。

/** 
* Display a pagination/grid list of rows. 
* 
* Requires $_REQUEST['order'] and $_REQUEST['dir'] 
* 
* @return void 
*/ 
public function listAction() 
{ 
    list($order, $dir) = $this->_validate($this->_request); 
    ... 

private function _validate($request) { 
    if (!$request->order) 
     throw new InvalidArgumentException('"Order" must be in request'); 

    if (!$request->dir) 
     throw new InvalidArgumentException('"Dir" must be in request'); 

    // maybe clean vars??? 
    //Zend_Filter_Numeric..... 

    return array($request->order, $request->dir); 
}

来源

2009-08-12 22:49:58

不错！我喜欢验证的想法。 – typeoneerror 2009-08-12 22:52:51

我通常要么使用你的建议，要么当代码太长，或者什么都不做时，使用简单的非phpdoc注释。

在这三者之间，我相信您的解决方案是最好的。

只有一件事你应该检查：当你正在生成phpdoc时，这个渲染很好吗？

从理论上讲，作为PHPDoc的使用您在文档块给的名字，我想这应该...

如果是......嗯，我没有看到一个更好的办法;不需要更好的方法：我认为你可以做任何比这更干净/可读/可理解的事情。

我不喜欢

@param string $order

的想法：没有显示$order应$_GET给予，而不是一个“真正的方法参数”;所以我宁愿避免这种语法。

我不会以用户为@var参数，顺便说一句：只为变量，当我觉得他们记录的需要（这是不是经常，至少在很短的代码方法/件）

来源

2009-08-12 22:43:05

请求参数和PHPDoc的

回答

相关问题