Когда я должен экспортировать функцию / переменную / константу в Golang? [Дубликат]

Я склонен использовать имена, используемые в нескольких разных файлах, и оставлять их строчными буквами, если они представляют интерес только для местного населения.

Короткий ответ: это не имеет значения. Возможно, на уровне сборки может быть выставлен указатель; но это не было указано.

И на самом деле, комментарии ошибочны в отношении godoc и публичных (столичных) писем. Для исполняемых файлов (основная часть пакета), godoc печатает только описание заголовка пакета //. Он не будет печатать какие-либо методы. Я пробовал это недавно и задавался вопросом, где была вся моя документация.

Вместо этого, что люди делают для приложений package main, это добавить файл с именем doc.go в свой пакет. Поскольку спецификация godoc позволяет вам украшать package main в любом месте любого файла, вы должны записать всю свою документацию здесь, в этом файле doc.go, например:

/* 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

Обратите внимание, что текст выше украшает package main в конце файла. Это весь текст в этом проекте doc.go.

Когда вы запустите go doc ., он будет читать этот файл для вывода.

Кроме того, при запуске основного приложения и используйте -h или -help, этот текст также отображается на консоли. Сделайте это так же тщательно, как вам нравится, чтобы помочь пользователям.

Изменить: как упоминает Джеймс, да, вы можете импортировать другие основные пакеты. Но это отступает от идиоматического характера Go в первую очередь. Документы в Go даже говорят, что дублирующий код, в интересах удобочитаемости, отлично подходит. Это было тяжело и для проглатывания, исходя из .NET и использования DRY-принципов.

Хотя это необычно, можно импортировать пакет с именем main из другого пакета. Рассмотрим следующие файлы в рабочей области Go:

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()
}

Я могу построить эти две программы как обычно, и bar может вызывать экспортированную функцию из пакета bar. Если это не было экспортировано, это было бы невозможно.

Это, очевидно, надуманный пример, но это может быть полезно, если у вас есть коллекция связанных программ, которые вы хотите скомпилировать. Очевидно, что было бы проще разделить общий код на отдельный пакет, не названный main.

Я спросил у Discord Gophers , и у Gopher Herder @LethalClips#4645 был подходящий ответ для меня.

Обычно вы будете экспортировать вещи только в основной пакет когда вам нужно, чтобы их читали извне библиотеки, такие как encoding/json, так как вы не хотите вручную импортировать основной пакет.

Этот ответ помог мне разобраться. Если он доступен библиотекой, экспортируйте его.