Длинные селекторы в Go

Нередко встречаю такой паттерн:

x := k.c.y.SetX()
// ...
if k.c.y.Exists()  { 
// ...

Функционально всё корректно, но цепочка k.c.y дважды нагружает зрение и увеличивает когнитивную нагрузку (cognitive load) — мозг вынужден каждый раз «проходить» всю селекторную цепочку (dot/point-chasing).

Я предпочитаю предварительно закэшировать конечный объект, создав локальный псевдоним (alias binding):

y := k.c.y
x := y.SetX()
// ...
if y.Exists() {
// ...

Почему это выглядит чище:

* Уменьшение числа селекторов (Number of Selectors, NOC): глубина доступа падает с 3 до 1, чтение ускоряется линейно
* Семантическая прозрачность (semantic transparency): конечный объект (y) получает собственный идентификатор, сразу видно его роль
* Нулевая стоимость абстракции (zero-cost abstraction): компилятор Go инлайнит псевдоним, нет лишних аллокаций и нагрузки на GC
* Снижение синтаксического шума (syntactic noise), анализаторы IDE реже ошибаются (поверил гуглу — сам не встречал)

P.S. ChatGPT конечно неплохо поработал с моим сумбурным текстом, добавил терминов, которые я и не слышал даже. Выглядит интересно

А вы боретесь с длинными селекторами (selector hell)?

И я тут же словил это в своём собственном VPN-боте. Ай я молодец

🔥🔥🔥 У меня пригорает от jira. Это уже 6-ой круг объяснения, что не так
А НАТЫКАЙТЕ МНЕ ТАМ СПРАВА ВВЕРХУ ГОЛОСОВ ЗА ТИКЕТ!!!!!! ПОЖАЛУЙСТА
https://jira.atlassian.com/browse/JSDCLOUD-16830

👻 На собеседованиях мешается «много языков». Только что «облажался», зависнув на условном m["key1"]++. Потому что оно в разных языках по-разному и я забыл в каком что

😮 Ой. А вы знали о такой ссылке?
https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/modernize

☝️ Вкратце — это тулза (и описание) для замены устаревших конструкций более модными. Из этой новости я узнал про min()/ max()

👻 Ухожу в монастырь. Пропустил slices.Contains(). Я не просто так пишу сюда, если что. Может не один я такой не слежу

👍 Кстати, очень хороший пример уместности дженериков