При написании одного пакета, предназначенного для использования в качестве команды, это идиоматично: назвать все идентификаторы как частные или назвать все идентификаторы как открытые?

Question

В Go публичные имена начинаются с заглавной буквы, а частные имена начинаются со строчной буквы.

Я пишу программу, которая не является библиотекой и представляет собой отдельный пакет. Есть ли какая-либо идиома Go, которая определяет, должны ли мои идентификаторы быть общедоступными или полностью частными? Я не планирую использовать этот пакет как библиотеку или как что-то, что должно быть импортировано из другой программы Go.

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

---

Я не думаю, что получил какой-то конкретный ответ, но Нейт был ближе всего к тому, чтобы сказать мне, что нужно думать об «экспорте против неэкспорта» вместо «публичного и частного».

Это заставляет меня верить, что не экспортировать что-либо - лучший подход. В худшем случае, если я в конечном итоге импортирую код из моего приложения в другой пакет, мне придется переосмыслить, что следует экспортировать, а что нет. Что хорошо, ИМО.

Answer 1

Если вы пытаетесь изменить свое мышление, чтобы оно стало более идиоматическим, вы должны перестать думать о переменных, функциях и методах как о публичных или частных.Более точный термин экспортируется или не экспортируется.Он определенно имеет больше ощущения C-стиля.

Как уже говорили, экспорт действительно не нужен для кода прикладной программы.Если по организационным причинам вы решили разбить свою программу на пакеты, вы можете использовать подпакеты.На работе мы решили сделать именно это.У нас есть:

projectgopath/src/projectname
                  projectname/subcomponent1
                  projectname/subcomponent2

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

Новые команды go build и go install, похоже, очень хорошо с этим справляются.Мы группируем компоненты в пакеты и выставляем только необходимые биты через экспорт.

Answer 2

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

Answer 3

Многие мои файлы go начали свою жизнь в изолированных командах и были перемещены в пакеты, так как их можно было повторно использовать несколькими командами в одной и той же теме.

Я думаю, что вы должны сделать приватным все, что не могло 'возможно вызвать из другого места (предположим, однажды вы сделаете его импортируемым пакетом) и обнародовать большие функции, которые можно понять из другого места (если они есть), и структурировать поля, когда они ортогональны (я имею в виду, когда изменение значенияодно поле не нарушает согласованность значения структуры).