Я хочу написать функцию в Go, чтобы вставить документ в коллекцию в базе данных MongoDB. Какой способ назвать функцию лучше,
writeToMongoDB илиWriteToMongoD?Второй - CamelCase, в то время как я видел кого-то, использующего стиль первого, поэтому я не уверен, какой из них более уместен. Спасибо.
В Go это не вопрос стиля, это вопрос синтаксиса.
Экспортированные имена (то есть идентификаторы, которые могут использоваться из пакета, отличного от того, где они определены) начинаются с заглавной буквы. Таким образом, если ваш метод является частью вашего общедоступного API, он должен быть написан:
WriteToDB
но если это внутренний вспомогательный метод, он должен быть записан:
WriteToDB
Преимущество такого использования с использованием ключевых слов для определения экспортности (extern, public и т.д.) заключается в том, что включение его в имя гарантирует, что в любом месте, где используется идентификатор, вы можете определить, экспортирован или нет, не найдя, где он был определен (чтобы определить, содержит ли определение ключевое слово).
См. также: Экспортированные идентификаторы из спецификации.
Поскольку Go кодируется в кодировке UTF-8 и поддерживает любой символ Юникода с использованием свойств букв или чисел в именах идентификаторов, некоторые люди в локалях, которые не имеют понятия, могут иметь проблемы с созданием экспортированных методов (по умолчанию неэкспортируется). В этом случае (предназначенный для каламбура) для префиксных идентификаторов обычно указывается X, указывающий на экспортность. Например: X日本語
См. также: Что происходит с идентификаторами Unicode? из FAQ.
Что касается общего стиля, то он всегда должен использовать верблюжьей кейс (за исключением первой буквы, как упоминалось ранее). Сюда входят константы, функции и другие идентификаторы. Так, например, список (экспортированных) констант может выглядеть так:
const (
StateConnected = iota
StateError
StateDone
internalStateMask = 0x2
)
Кроме того, аббревиатуры всегда записываются в одном и том же случае, поэтому вы должны написать одно из следующих значений:
dbWrite
writeDB
вместо writeDb или DbWrite.
В Go, принято использовать смешанную кепку. Из документов: https://golang.org/doc/effective_go.html#mixed-caps
Наконец, соглашение в Go состоит в том, чтобы использовать MixedCaps или mixedCaps чем подчеркивания для написания имен многослов.
Обратите внимание, что имена файлов, начинающиеся с буквы Capital, экспортируются на уровне пакета: https://golang.org/doc/effective_go.html#Getters
Кроме того, принято писать аббревиатуры на всех шапках. Итак, ниже хорошо:
writeToMongoDB // unexported, only visible within the package
или
WriteToMongoDB // exported
И не:
writeToMongoDb
Имена
Имена так же важны, как и на любом другом языке. У них даже есть семантический эффект: видимость имени вне пакета определяется, является ли его первый символ верхним регистром. Это поэтому стоит потратить немного времени на именование соглашения в программах Go.
Имена пакетов
Когда пакет импортируется, имя пакета становится аксессуаром для содержимое. После того, как
импортировать "байты" в пакет импорта может говорить о байтах .Buffer. Это полезно, если все, использующие пакет, могут использовать одно и то же имя для ссылки к его содержимому, что означает, что имя пакета должно быть хорошим: короткий, лаконичный, вызывающий воспоминания. По соглашению, пакеты даются ниже case, однословные имена; не должно быть необходимости подчеркивать или mixedCaps. Err на стороне краткости, поскольку все, кто использует ваши пакет будет набирать это имя. И не беспокойтесь о столкновениях априори. Имя пакета - это только имя по умолчанию для импорта; это необходимо не быть уникальным по всему исходному коду, а в редком случае collision, импортирующий пакет может выбрать другое имя для использования на местном уровне. В любом случае путаница редка, потому что имя файла в import определяет, какой пакет используется.
Другое соглашение состоит в том, что имя пакета является базовым именем его исходный каталог; пакет в src/encoding/base64 импортируется как "encoding/base64", но имеет имя base64, а не encoding_base64, а не encodingBase64.
Импортер пакета будет использовать это имя для обозначения его содержимого, поэтому экспортированные имена в пакете могут использовать этот факт, чтобы избежать заикания. (Не используйте импортную нотацию, которая может упростить тесты, которые должны запускать вне пакета, который они тестируют, но в противном случае избегали.) Например, буферизованный тип считывателя в пакете bufio называется Reader, а не BufReader, потому что пользователи видят его как bufio.Reader, который является ясным, сжатым названием. Более того, поскольку импортируемые объекты всегда обращаются с их именем пакета, bufio.Reader не конфликт с io.Reader. Аналогично, функция создания новых экземпляров of ring.Ring - это определение конструктора в Go-will обычно называются NewRing, но поскольку Ring является единственным экспортированным типом по пакету, а так как пакет называется кольцом, он называется просто Новый, который клиенты пакета видят как ring.New. Использовать пакет чтобы помочь вам выбрать хорошие имена.
Еще один короткий пример - один раз. once.Do(setup) хорошо читается и будет не следует улучшать путем написания once.DoOrWaitUntilDone(настройка). Длинные имена не делайте это автоматически более удобным для чтения. Полезный комментарий к документу часто может быть более ценным, чем добавочное длинное имя.
Геттеры
Go не обеспечивает автоматическую поддержку для получателей и сеттеров. Там в ничего плохого в том, чтобы предоставлять геттеры и настройки сами, и это часто подходит для этого, но это не является ни идиоматическим, ни необходимым поместить Get в имя получателя. Если у вас есть поле, называемое владельцем (нижний регистр, не экспортированный), метод геттера должен называться Owner (верхний регистр, экспортируется), а не GetOwner. Использование имен верхнего регистра для экспорт обеспечивает привязку для выделения поля из метода. setter, если необходимо, скорее всего, будет называться SetOwner. Оба названия хорошо читайте на практике:
owner := obj.Owner()
if owner != user {
obj.SetOwner(user)
}
Имена интерфейсов
По соглашению, интерфейсы одного метода называются именем метода плюс суффикс -er или аналогичную модификацию для создания существительного агента: Reader, Writer, Formatter, CloseNotifier и т.д..
Существует множество таких имен, и это полезно для их соблюдения и имена функций, которые они фиксируют. Чтение, запись, закрытие, флеш, строка и так и имеют канонические подписи и значения. Чтобы избежать путаницы, не давайте вашему методу одно из этих имен, если оно не имеет того же подпись и значение. И наоборот, если ваш тип реализует метод с тем же значением, что и метод на известном типе, одно и то же имя и подпись; вызов метода строкового преобразователя String not ToString.
MixedCaps
Наконец, соглашение в Go состоит в том, чтобы использовать MixedCaps или mixedCaps чем подчеркивание для написания имен нескольких слов.
ref: Эффективный ход
В Golang любая переменная (или функция) с идентификатором, начинающимся с буквы верхнего регистра (например, CamelCase), становится общедоступной (доступной) ко всем другим пакетам вашей программы, тогда как те, которые начинаются с нижнего регистра письмо (например, camelCase) недоступно для любого пакета, кроме того, который он объявляет.
Вы должны использовать CamelCase в случае, если вы намерены использовать переменную (или функцию) в другом пакете или можете безопасно придерживаться camelCase.