在导出的名称上排除 godocs 是否是不好的做法?

huangapple go评论81阅读模式
英文:

Is it bad form to exclude godocs on exported names?

问题

根据《Effective Go》golang.org/doc/effective_go的说法:

程序中的每个公开(首字母大写)的名称都应该有一个文档注释。

假设我在一个简单的 Web 应用程序中有一个视图处理程序:

// 处理网站的首页
func FrontPageView(w http.ResponseWriter, r *http.Request) {
    controllers.RenderBasicPage(w, "frontPage") 
}

我的问题是:这个 godoc 是否真的必要?也许我现在只是迷恋 Robert Martin 的《代码整洁之道》,但是在这种情况下,一个命名得当的变量,比如 FrontPageView,似乎就不需要这样的 godoc。这可能是一个派生/重复的问题,类似于“是否需要 javadocs?”或“是否需要 Python 的文档字符串?”,但是我确实希望在学习一门新语言时能够遵循特定语言的规范方式来做事情。

英文:

According to "Effective Go" golang.org/doc/effective_go

> Every exported (capitalized) name in a program should have a doc comment.

Let's say I have a view handler on a simple web application

// Handle the front page of the website
func FrontPageView(w http.ResponseWriter, r *http.Request) {
    controllers.RenderBasicPage(w, "frontPage") 
}

My question is this: is that godoc really necessary? Perhaps I'm just in love with Robert Martin's Clean Code right now, but it seems an effectively named variable, in this case FrontPageView removes the need for such a godoc. This is probably a derivative/duplicate of "are javadocs necessary?" or "are python docstrings necessary?", but I do want to make sure that when learning a new language I'm sticking to the language-specific canonical ways-to-do-things.

答案1

得分: 13

请注意,golint会告诉你,FrontPageView()的文档必须以以下方式开始:

// FrontPageView ...

而且,良好的实践是在所有公开的方法和函数中包含(这里是简短的)注释,如“Go代码审查评论”中所述。

文档化声明的注释应该是完整的句子,即使这似乎有点多余。这种方法使它们在提取到godoc文档中时格式良好。

注释应该以被描述的事物的名称开头,并以句点结尾:

// Request表示一个运行命令的请求。
type Request struct { ...

// Encode将req的JSON编码写入w。
func Encode(w io.Writer, req *Request) { ...

我的理解是,有效的清晰代码意味着保持函数简单,具有描述函数唯一角色的名称;

然后文档可以包括边缘情况(即使在你的情况下没有)。无论如何,添加一个简短的文档不会使它“不够清晰”。

随着它们变得更复杂,你可以将它们拆分为多个同样简单的函数。

我使用gocyclo来实现这一点:任何超过10的cyclomatic complexity,我都会将函数拆分。

此外,更改还需要更新godoc以及名称。

这就是想法:保持文档同步(golint有助于此)。

英文:

Note that golint would tell you that the doc for FrontPageView() must start with

// FrontPageView ...

And yes, it is good practice to include (here a short) comment on all exported methods, functions, as described also in "Go Code Review Comments".

> Comments documenting declarations should be full sentences, even if that seems a little redundant.
This approach makes them format well when extracted into godoc documentation.

> Comments should begin with the name of the thing being described and end in a period:

// A Request represents a request to run a command.
type Request struct { ...

// Encode writes the JSON encoding of req to w.
func Encode(w io.Writer, req *Request) { ... 

> it's my understanding that effectively clean code means keeping functions simple with a name that describes the function's one role;

Then the doc can include edge cases (even if in your case there are none).
In any case, adding a short doc won't make it "less clean".

> as they get more complex you split them into multiple, equally simple, functions.

I use gocyclo for this: any cyclomatic complexity above 10, and I split the function.

> Also, changes would require an update in the godoc as well as the name

That is the idea: keeping the doc in sync (and golint helps)

答案2

得分: 5

以下是写文档注释的几个原因:

  • Lint。如果你使用golint,它会在每个没有文档注释的公开方法上打印警告。如果你有很多这样的方法,你可能会不小心忽略应该记录的内容。在代码中没有golint警告可以让你在文档缺失或其他样式不一致时能够快速反应。

  • 变更。代码一直在变化。也许现在你的FrontPageView只是一个没有内容的一行代码,但将来它可能变得更加复杂,所以你仍然需要添加文档注释来解释发生了什么。

  • Grep。在你的例子中,如果我是一个新开发者,被分配了一个与首页有关的任务,我可能会执行godoc pkg | grep 'front page'git grep 'front page'。如果你没有提供文档注释,这两个命令对我来说可能都没有用,我要么必须启动godoc网页界面来查找,要么尝试其他几个grep命令。

英文:

Here is a couple of reasons to write doc comments:

  • Lint. If you use golint, it will print warnings on every exported method that has no doc comment. If you have a lot of those you can accidentally miss something that should actually be documented. Having zero golint warnings in your code allows you to react quickly when the docs are missing somewhere or you have other style inconsistencies.

  • Changes. The code changes all the time. Maybe now your FrontPageView is a one-liner with no content, but in the future it might become more complex, so you'll have to add a doc comment anyway to explain, what's going on.

  • Grep. In your example, if I am a new developer and I'm given a task having to do with the front page, I will probably do godoc pkg | grep 'front page' or git grep 'front page'. If you don't provide a doc comment, both of those will probably be useless for me, and I'll have to either launch the godoc web interface to look for it with my eyes, or try a few other greps.

huangapple
  • 本文由 发表于 2014年11月17日 21:23:03
  • 转载请务必保留本文链接:https://go.coder-hub.com/26973714.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定