Mahdi.Kh
September 21, 2026
We learn how to write documentation and publish it, and also learn how to use Godoc.
One part of programming is writing documentation for code. Writing documentation increases the software's extensibility and accessibility.
Go has a tool called Godoc that scans code and makes the documentation provided within it available to us as web pages.
The comments that godoc looks at aren't part of the Go language's structure and don't need any special, machine-parsable syntax. In fact, godoc comments are just ordinary, good-quality comments that are useful and understandable to developers even without godoc.
In general, to document a data type, variable, constant, function, or even a package, it's enough to write an ordinary comment right before its declaration, with no blank line between the comment and the declaration, so that godoc displays this comment as the documentation for that item.
For example, inside the fmt package there's a function named Fprintln that has a comment like this:
These comments end up being published in the package's published documentation.
Each of these comments is a complete sentence and begins with the name of the very element it describes. Following this important convention makes it possible to produce documentation in a variety of formats — from plain text to HTML and even UNIX man pages. In addition, when tools display a summarized part of the documentation (for example, extracting only the first line or the opening sentence), the output still stays readable and understandable.
Comments written for a package declaration should provide a general explanation of that package's purpose, usage, and contents. For example, the sort package has a comment like this in its documentation:
If your package's documentation is quite lengthy, you can create a doc.go file inside your package and put your documentation in this file. Usually this file contains only documentation, with no Go code written inside it. For example, the gob package has a doc.go file. The comments placed inside the doc.go file are also published in the package's documentation. For example, the documentation for the gob package consists of exactly the .
Note: when writing a comment for a package, regardless of its size, remember that the comment's first sentence is shown in godoc's package listing; so it's best for this sentence to be an accurate summary of the package's purpose and usage.
Comments that aren't placed directly before any top-level declaration are not shown in godoc's output. There is, however, one important exception: top-level comments that start with BUG(who) are recognized as known bugs and are shown in the Bugs section of the package's documentation. The value of who should be the username of the person who can provide more information about that issue. For example, the following is a known bug in the bytes package:
Sometimes a field of a struct, a function, a data type, or even an entire package is no longer used or no longer needed, but it has to remain in place to preserve compatibility with older programs. In such cases, to indicate that an identifier should no longer be used, add a paragraph starting with Deprecated: to its documentation, followed by the reason or explanation for the deprecation, so it's shown in the documentation.
There are several simple rules that, if followed, make the documentation godoc produces more consistent in structure:
The important thing is that none of these rules force you to do anything complicated or unusual. In fact, one of the strengths of godoc's simple approach is exactly this ease of use. That's why a large portion of Go code, including the entire standard library, follows these conventions. Your code, too, can produce proper documentation just by following these same simple commenting principles.
All Go packages located under $GOROOT/src/pkg, as well as packages in GOPATH workspaces, are accessible through godoc's command-line interface and HTTP interface. You can also use the -path flag to specify other paths to be indexed, or simply run the following command in your source folder:
Also, if you need the documentation to be served on a specific port, we can use the -http flag:
For more details, you can check the godoc documentation.
There's more detailed information about Go's documentation conventions, which you can find by checking the Go documentation.
Previous part: Introducing go fix | Golang basics