Уже не первый раз сталкиваюсь с такой проблемой: Есть структура emailsManager,

я ее инициализирую и присваиваю переменной. Как правильно назвать эту переменную? Хочется назвать так же emailsManager, но так нельзя сделать. Всякие сокращение eManager не очень явно выглядят. Как вы поступаете в таких случаях?

em

Это тоже не явное название, встретив такое в коде я задумаюсь что же это такое.

Для локального скоупа сойдет. Если у вас функции конечно не сотни строк

У меня функция, которая используется во всем коде программы в разных пакетах

Да и пожалуйста. Это же внутренняя переменная

func (um *UserManager) Add(ctx context.Context, u *User) error { return um.userRepo.Add(ctx, u) } Зачем тут длинные имена?

Тут не за чем. Но это не мой вариант. У меня сложность при инициализации. emailManager = new(emailManagerStruct)Но я решил проблему добавлением struct к названиям всех структур

new лишь выделит память, инициализации полей структуры не будет.

Прям всех структур? Ну ок, но это плохой стиль)

Это лишь один пример. Есть места где я делаю через, сути это не меняет. emailManager = &emailManagerStruct{ username: "username", password: "password", }

А что у вас эти менеджеры делают?

``` emailManager = &tEmailManager{ username: "username", password: "password", } ```

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

а emailManager не зависит от logManager? ;)

Как вариант, но мне такой синтаксис не особо близок. Этот вариант чем-то лучше чем постфикс struct? Или только лишь кому как нравится?

кому как нравится

emailManager может использовать logManager, если надо будет залогировать неуспешную отправку письма. А logManager может использовать emailManager, если ему понадобится отправить письмо.

Если это либа или тула для внутреннего пользования - называйте как нравится) если на люди выкладывать собираетесь - стоит ещё раз подумать

Это к вопросу о выборе между префиксом t и постфиксом struct? Или тут в целом стоит задуматься об изменении концепции менеджеров?

А как вы преодолеваете циклические импорты?

если внутренний проект как хочется \ как привыкли так и называете. Внешний будет либа.Тип, там без префиксов суффиксов все ясно по либе

Это когда в logManager и emailManager импортируют одно и то же?

Скорее второе. Если появляется куча однотипных имён lalaSuffix, blahSuffix, kekSuffix, то возможно стоит подумать о том чтоб завести пакет suffix и звать объекты оттуда. Но тут на усмотрение уже, я кода не видел и вслепую советовать плохая практика

когда logManager импортирует emailManager, а emailManager - logManager

Вот оно что, понял вас.

+

Сейчас это все внутри одного общего пакета, они не вынесены в отдельные либы. Хотя сейчас стал думать об этом, т.к. они в будущем могут понадобиться и в других проектах.