代码之家  ›  专栏  ›  技术社区  ›  Dor

文档样式[关闭]

  •  0
  • Dor  · 技术社区  · 16 年前

    我是一个PHP Web开发人员,他正在寻找一种行之有效的方法来编写一个好的文档(又名docblock)。

    有几种文档样式,例如:

    • 描述性但未分类(1):
    /**
     *  Element name: class, function, variable etc. (Optional)
     *  
     *  Short description.
     *
     *  Long description.
     */
    
    • 分类(2):
    /**
     *  Function name
     *
     *  @param $foo
     *  @return bar
     */
    
    • 类似(3)的模板:
    /**
     **********************
     * NAME:    Func_Name
     * DESC:    Does A Lot
     * RETurn:  number
     * NOTES: foo bar foo...
     **********************
     */
    
    • 上述方法的变更。

    但我应该采用哪种文档样式?

    我假设不同的文档样式应该用于不同的语言元素:
    函数可能应该使用2方法,
    而类应该使用1方法。

    内联代码可以这样记录(5):

    // short description
    // of
    // what the following code does.
    

    我知道phpdocumentor,但不喜欢学习如何使用它。
    学习如何使用phpdocumentor之类的东西,以便记录我的代码,这似乎很荒谬。
    (尽管我很欣赏任何开源项目,包括phpdocumentor)

    1 回复  |  直到 16 年前
        1
  •  1
  •   Uri    16 年前

    其他人可能会告诉你关于PHP的更具体的事情。

    不过,我认为最重要的是“谁会在什么时候读到这本书”。如果您正在编写一些您希望很多人使用和阅读的主要API,那么您需要提供一个完整的规范。一种很好的正式样式,它清楚地显示参数是什么、返回值是什么等,可能几乎是强制的。

    如果您不是在编写世界级的API,而是在编写内部代码,请考虑您的读者。大多数读过这篇文章的人都会对代码进行润色。他们将实例化一个类或调用一个方法来完成某件事情,并且他们不会关心任何他们自己能想到的事情。当他们略读的时候,你只会得到一两秒钟的注意力,你必须充分利用这一点。

    在这些情况下,一个完整的描述、一个完整的参数列表等等都只是“视觉噪声”。如果你真的写了一些令人惊讶的、独特的或重要的东西,可能会错过。所以你最好选择只记录独特的东西,而不是记录其他东西。文档的存在将向您的读者表明他们实际上想要阅读,而不是注意到他们期望的其他内容。

    除此之外,我认为您应该始终仔细设计您的类,尤其是您的函数,以便没有人需要阅读文档。如果有人需要阅读“简短描述”来了解您的函数的作用或需要什么,那么您在命名它或将它与其他函数区分开来方面做得很糟糕。文档应该是最后的手段,用来传递那些在签名中根本没有明显方法的东西。