Effective Go и ряд других вики-сайтов и сайтов, призывающих программиста Go использовать простые имена для пакетов и избегать чего-то слишком общего, например 'misc' или 'utils'.
Кроме того, Go избегаетмногоуровневые пространства имен - у него есть один уровень - имя пакета.
Итак, имена пакетов простые, но не более одного или двух слов, специфичные для темы.
И еще естьнет способа внедрить новый код в существующий пакет, так что, например, то, что находится в 'os', по существу запечатано автором любой версии пакета 'os', который я выбрал для использования (очень вероятно, пакет Go os).
Но здесь я остаюсь, почесывая голову.
Как мне написать собственную хорошую библиотеку, которая расширяет существующие концепции / пакеты, такие как os или fmt иличто-то такое общее, как «расширяет типы карт» в пакет или набор пакетов для совместного использования среди моих собственных проектов (или моей организации, или, может быть, публично в срок)?
В качестве одного произвольного примера, давайтескажем, мне обычно нужна функция, такая как GetEnvOrDefault(key, def string) string
Это полезно. Он может быть написан длинной строкой как набор операторов if, но самодокументируется и немного короче, чтобы писать один раз, и позволяет клиентскому коду потреблять и быть немного короче и более кратким по своему значению (менее визуальный анализ для GetEnvOrDefault'против прописанного кода снова и снова и снова - в данном случае:
// GetEnvOrDefault returns the specified environment variable's contents, or the specified default value if that env var is not present
func GetEnvOrDefault(key, defvalue string) string {
value := os.Getenv(key)
if len(value) == 0 {
value = defvalue
}
return value
}
Это всего лишь один пример. Он короткий, чтобы его можно было вписать в него и легко обсуждать. Я собираюсьвыйдите на конечность и предположите, что вы можете придумать произвольный, более сложный пример, в котором нет сомнений, что вы хотите поместить его в библиотеку, чтобы один раз написать и отладить его, а затем использовать и использовать несколько проектов. функциональность.
Как назвать этот пакет?
Не «utils» и «misc», поскольку это слишком чертовски в Go. Не может быть «os», поскольку оно эффективно запечатано. быть «организация / ОС», так как мы не можем сделать многоуровневые пространства имен. Не должно быть «организация_ос», поскольку это не идиоматично для Go.
Так что же нас оставляет?
'osx' - хм ... 'osex' - забавно, но ... 'osmisc' - кажется уродливым / плохим ... 'env' - хорошо, конечно, но это супер универсально - сколько я хочу поставитьуже есть пакеты, более заслуживающие этого имени, которые могут вступить в конфликт в будущем ...
вы меня чувствуете?
Это один из примеров. Но у меня есть полезные расширения для JSON, uuid, карт, 32-битной математики, http-серверов, http-клиентов, ...
Что делает программист?
Copyтакой маленький разныйслужебные функции и типы для каждого проекта?
Придумайте очень неидиоматические имена для пакетов?
Какие предложения вы можете предложить?