Public names in an executable ("main" package)

As I understand it, names that are capitalized are exported (public) when the package is imported. However, since executables ("main" packages) are run instead of being imported by other packages, what difference does it make whether names are public or not? Should I make all names private as a matter of principle?

The short answer is: it doesn't matter. Perhaps on an assembly level there may be an exposed pointer; but, it hasn't been stated.

And actually, the comments are wrong about godoc and public (capital) letters. For executables (package main), godoc only prints the package's // header description. It will not print any methods. I tried this recently and was wondering where all of my documentation was.

Instead, what people do for package main apps is to add a file called doc.go to their package. Since the godoc specification allows you to decorate the package main anywhere in any file, you would write all of your documentation here, in this doc.go file like so:

/* This executable serves a special purpose 
and that is say Hello World when it is run.

A tip for writing comments in go is to use 
line-break, text, line-break to make headers, 
like this.

This Is A Header

And the sub-text to the header goes here.

Also note that you can create indented 
code with 4 spaces...

   Like this.
   And this.

And the above will be printed as code
blocks in -html output.

*/
package main

Note that the text above decorates package main at the end of the file. That is all the text in this doc.go project.

When you run go doc ., it will read this file for the output.

Also, when you run the main app and use the -h or -help, this text is also rendered to the console. Make it as elaborate as you like to help users.

Edit: as James mentions, yes you can import other main packages. But that deverges from the idiomatic nature of Go in the first place. The docs at Go even say that duplicating code, in the interest of readability, is perfectly fine. That was hard for me to swallow too, coming from .NET and using DRY principals.

While it is unusual, it is possible to import a package called main from another package. Consider the following files in a Go workspace:

src/foo/foo.go:

package main

import "fmt"

func Doit() {
    fmt.Println("Doit() called")
}

func main() {
    fmt.Println("Calling Doit from foo")
    Doit()
}

src/bar/bar.go:

package main

import (
    "fmt"
    foo "foo"
)

func main() {
    fmt.Println("Calling Doit from bar")
    foo.Doit()
}

I can build these two programs as normal, and bar can call the exported function from the bar package. If it wasn't exported, then this wouldn't be possible.

This is obviously a contrived example, but it could be useful if you have a collection of related programs you want to compile. Obviously, it would cleaner to split the shared code out into a separate package not named main.

I tend to capitalize names that are used in several different files, and leave them lowercase if they are only of local interest.

I asked on Discord Gophers, and Gopher Herder @LethalClips#4645 had an appropriate answer for me.

> You generally will only be exporting things in the main package when you need them to be read externally by libraries like encoding/json, as you don't want to be manually importing the main package.

This answer helped me to sort it out. If it's accessed by a library, export it.