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