Стиль програмування здорового розробника

tl;dr:
- один і лише один рівень відступів на метод
- використовувати ранній вихід з методу
- не використовувати else
- жодних абревіатур

Тут і надалі для наочності використовується псевдокод

Рівні вкладеності

Дуже відомий антипаттерн, який називається IfOk: код бізнес-логіки повинен виконуватися лише в тому випадку, якщо умови для цього є дійсними. У коді цей виглядає приблизно так

if (ok) {
   callA()
   if (A_ok) {
     callB()
     callC()
     if (B_Ok AND C_ok) {
       callD()
       callE()
       callF()
       callG()
     } else
       throwException("Method A failed")
   } else
     throwException("Method B or C failed")
} else
   throwException()

В наявності всі можливі недоліки:

• заплутана бізнес-логіка
• обробники помилок далеко від місця виникнення самих помилок
• багато рівнів вкладеності
• просто багато коду

Вирішенням проблеми є патерн IfError:

if (error)
   throwException()

callA()
if (A_error)
   throwException("Method A failed")

callB()
callC()
if (B_error OR C_error)
   throwException("Method B or C failed")

callD()
callE()
callF()
callG()

Переваги:

• поділ обробки помилок та бізнес-логіки
• обробники помилок біля місць виникнення помилок
• один рівень вкладеності
• менше коду

Фантастичні ELSE і де вони мешкають

Вам відомий такий стиль написання коду?

method(argument) {
   if (argument is ok)
     return a
   else if (argument is not ok)
     return b
   else
     return з
}

Що має статися, щоб після return спрацював else?! Не потрібний тут else, взагалі. Тут і далі патерн раннього повернення:

method(argument) {
   if (argument is ok)
     return a

   if (argument is not ok)
     return b

   return c
}

return повинен бути на першому рівні вкладеності всього методу або ж на другому, якщо це раннє повернення

Абревіатури

Хоча в екосистемі golang і прийнято скрізь використовувати змінні з однієї літери та абревіатури, мені здається це поганою витівкою

method(attrs, args, clss) {
   dump("Attributes", attrs)
   dump("Arguments", args)
   dump("Classes", clss)
}

Комп’ютеру все одно як названі змінні, геть-чисто. Називайте їх зручно для себе та інших розробників. Адже лише через кілька днів після написання такого коду буде складно згадати, що таке kls без контексту