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

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)
}

Компьютеру без разницы как названы переменные, напрочь. Называйте их удобно для себя и других разработчиков. Ведь всего через несколько дней после написания такого кода будет сложно вспомнить, что такое clss без контекста