Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/godoc: parameter/return field #18897

Closed
mattn opened this issue Feb 2, 2017 · 8 comments
Closed

proposal: cmd/godoc: parameter/return field #18897

mattn opened this issue Feb 2, 2017 · 8 comments

Comments

@mattn
Copy link
Member

mattn commented Feb 2, 2017

In sometimes, I hope to know the meaning of function parameters in source code. However, most of godoc(s) comment are just explaining abridgely like // XXX create Writer from w. This often makes confusing especially for non-english speakers. So I hope to add syntax to make documentation like doxygen or javadoc in godoc comment.

Note: I give you due warning, I don't mean that all of go codes must be complying this syntax. Just providing way to create useful documentation.

// CreateDocument create document file on the directory path.
// @param path Path to the directory to create the document file.
// @param mode Mode to switch Rich/Simple mode.
// @return filename created
// @return error when occured
func CreateDocument(path string, mode Mode) (string, error) {
   //...
}

godoc command generate html table tag from the parameter/return directives. I know that you have many different opinions about this. Someone doesn't like this syntax. And maybe it need more syntax is needed. However, this may be useful to read/write documentation, and know what the parameter/return value is meaning, I guess.

Thanks.

@ericlagergren
Copy link
Contributor

Suggestion/question: couldn't go lint be changed to complain if explanations for the parameters are omitted?

@minux
Copy link
Member

minux commented Feb 2, 2017 via email

@mattn
Copy link
Member Author

mattn commented Feb 2, 2017

Revently, I deliver products written in Go for my customers with godoc documentation. The documentation is written in english currently. godoc is beautiful look to see documentation.

However all of programmers cannnot write english in the world. As I said in above, // XXX make bytes.Buffer from w often makes confusing in non-english speakers. If possibly, we have better to provide the way to write godoc for non-english people.

In additional, godoc accept to write in free style. So often, I forgot to add description of new parameters. As @ericlagergren said, varidator will be useful to check whether the documentation is broken.

@mattn
Copy link
Member Author

mattn commented Feb 2, 2017

I say again, I don't want to add complying. Just want to add extensible for the documentation. For example, This is one of the way to do.

$ godoc -html -formatter ./path/to/formatter .

@rsc rsc changed the title proposal: parameter/return field in godoc proposal: cmd/godoc: parameter/return field Feb 6, 2017
@rsc
Copy link
Contributor

rsc commented Feb 6, 2017

There is a hook in the packages that godoc uses that can be used to turn all references to certain names into code font, so that parameters can be shown in a separate font. But it's unclear if that's sufficient for your needs.

We don't want to add explicit markup, like @param and @return, even optionally. It's important that doc comments read as ordinary comments, without needing to know about special syntax.

@rsc rsc added this to the Proposal milestone Feb 6, 2017
@minux
Copy link
Member

minux commented Feb 7, 2017 via email

@ericlagergren
Copy link
Contributor

@rsc this isn't my issue, but I'd appreciate having parameter names be in code.

@rsc
Copy link
Contributor

rsc commented Feb 13, 2017

As noted before, one of the first principles of godoc comments is to avoid markup like @param.

@rsc rsc closed this as completed Feb 13, 2017
@golang golang locked and limited conversation to collaborators Feb 13, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants