Программирование — это искусство. Мастера своего дела, создающие потрясающие работы, могут ими гордиться. То же самое относится и к программистам, которые пишут код. Чтобы достичь вершин мастерства, творцы постоянно ищут новые подходы к работе и новые инструменты.
Так поступают и разработчики, которые, не прекращая профессионально развиваться, постоянно стремятся найти ответ на самый важный свой вопрос: «Как писать хороший код?». Вот что говорит об этом Фредерик Брукс в книге «Мифический человеко-месяц, или Как создаются программные системы»:
Программист, подобно поэту, работает с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов.
Как писать хороший код (источник)
В этом материале сделана попытка найти ответ на большой вопрос из вышеприведенного комикса. Самый простой способ писать хороший код заключается в том, чтобы не употреблять в своих программах так называемые «антипаттерны».
Что такое антипаттерны
Антипаттерны проникают в код тогда, когда программы пишут, не принимая во внимание вопросы, связанные с их использованием в будущем. Может случиться так, что то, что называют «анти-паттерном», в определенный момент может показаться приемлемым решением некоей задачи. Но, на самом деле, по мере роста кодовой базы подобные решения оказываются малооправданными, увеличивая технический долг проектов.
В качестве простого примера проникновения в код антипаттерна можно привести ситуацию, когда при создании API не учитывается то, как именно потребитель этого API будет им пользоваться. Этому посвящён наш первый рассказ об антипаттерне.
Знание антипаттернов и сознательное предотвращение их использования в ходе написания кода — это, без сомнения, чрезвычайно важный шаг на пути к улучшению читабельности и поддерживаемости кодовой базы.
Рассмотрим некоторые распространённые антипаттерны, встречающиеся в коде, написанном на Go.
1. Возврат значения неэкспортируемого типа из экспортируемой функции
В Go, для экспорта любого поля или любой переменной, нужно, чтобы имя поля или переменной начиналось бы с большой буквы. Сущности экспортируют из пакетов для того чтобы они были бы видны другим пакетам. Например, если в программе нужно воспользоваться константой Pi из пакета math, то обращаться к ней надо с помощью конструкции math.Pi. Использование конструкции math.pi приведет к возникновению ошибки.
Имена (это относится к полям структур, к функциям, к переменным), которые начинаются с маленькой буквы, являются неэкспортируемыми, они видны только в пакете, в котором они объявлены.
Если экспортируемая функция возвращает значение неэкспортируемого типа — это может привести к неудобствам, так как тому, кто вызывает эту функцию из другого пакета, придётся самостоятельно определить тип этого значения для его использования.
// Не рекомендовано
type unexportedType string
func ExportedFunc() unexportedType {
return unexportedType("some string")
}
// Рекомендовано
type ExportedType string
func ExportedFunc() ExportedType {
return ExportedType("some string")
}
2. Неоправданное использование пустых идентификаторов
В целом ряде ситуаций присвоение значений пустому идентификатору нецелесообразно. Вот, например, что сказано в спецификации Go об использовании пустого идентификатора в циклах for:
Если последней итерационной переменной является пустой идентификатор, то выражение range эквивалентно такому же выражению без этого идентификатора.
3. Использование циклов или нескольких вызовов append для объединения срезов
Если нужно объединить пару срезов — нет нужды перебирать один из них в цикле и присоединять элементы к другому срезу по одному. Вместо этого гораздо лучше и эффективнее будет сделать это в одном вызове функции append.
В следующем примере объединение срезов выполняется путём перебора элементов sliceTwo и присоединения этих элементов к sliceOne по одному:
Но известно, что append — это вариативная функция, а это значит, что её можно вызывать с разным количеством аргументов. В результате предыдущий пример можно значительно упростить и переписать с использованием функции append:
4. Избыточные аргументы в вызовах make
В Go имеется особая встроенная функция make, которая используется для создания и инициализации объектов типов map (ассоциативный массив), slice (срез), chan (канал). Для инициализации среза с использованием make нужно предоставить этой функции, в виде аргументов, тип среза, его длину и емкость. При инициализации ассоциативного массива с помощью make нужно передать функции размер этого массива.
Правда, пользуясь make, нужно знать о том, что у этой функции уже имеются значения, назначаемые соответствующим аргументам по умолчанию:
В случае с каналами емкость буфера устанавливается в 0 (речь идёт о небуферизованном канале).
В случае с ассоциативными массивами размер по умолчанию устанавливается в небольшое начальное значение.
В случае со срезами емкость по умолчанию устанавливается в значение, равное указанной длине среза.
Вот неудачный пример использования make:
Этот код можно переписать так:
Надо отметить, что использование именованных констант при создании каналов не считается анти-паттерном в тех случаях, когда речь идёт об отладке, о применении результатов неких вычислений, о написании кода, жёстко привязанного к какой-либо платформе.
5. Ненужное выражение return в функциях
Не рекомендуется ставить в конец функции выражение return в том случае, если функция ничего не возвращает.
При этом надо отметить, что возврат с помощью return именованных возвращаемых значений не стоит путать с бесполезным использованием return. Например, в следующем фрагменте кода return возвращает именованное значение:
6. Ненужные команды break в выражениях switch
В Go выражения switch устроены так, что при выполнении одного из вариантов кода, описываемого в блоке case, код блоков case, которые следуют за ним, выполняться не будет. В других языках, наподобие C, выполнение кода должно быть явным образом прервано с помощью команды break. В противном случае, если, например, в switch нет ни одного break, после выполнения кода одного блока case выполняется и код следующих за ним блоков. Известно, что эта возможность в выражениях switch используется очень редко и обычно вызывает ошибки. В результате многие современные языки программирования, вроде Go, отказались от такой схемы выполнения выражений switch.
В результате в конце блоков case нет необходимости пользоваться командами break. Это значит, что оба нижеприведенных примера дают один и тот же результат.
Но, если нужно, в switch можно реализовать переход к последовательному выполнению кода блоков case. Для этого используется команда fallthrough. Например, следующий код выведет 23:
7. Отказ от использования стандартных вспомогательных функций для решения распространённых задач
В Go существуют краткие варианты определенных функций, вызываемых с особым набором аргументов. Эти варианты функций можно использовать для повышения эффективности программ, для улучшения их читабельности, для того чтобы сделать их понятнее.
Например, в Go, для организации ожидания завершения выполнения нескольких горутин, можно использовать счетчик sync.WaitGroup. При работе с ним могут применяться вспомогательные функции. В частности — функция wg.Add() (переменная wg в наших примерах имеет тип sync.WaitGroup), позволяющая добавить нужное количество горутин в группу. Когда горутина из группы завершает выполнение, счетчик уменьшают, вызывая функцию wg.Add() с передачей ей -1:
Если говорить о конструкции wg.Add(-1), то, вместо того, чтобы использовать её для ручного декрементирования счетчика, можно воспользоваться функцией wg.Done(), которая тоже декрементирует счетчик, уменьшая его значение на 1, но при этом выглядит лучше и понятнее, чем wg.Add(-1):
8. Избыточные проверки на nil при работе со срезами
Длина «нулевого» (nil) среза приводится к 0. Это значит, что не нужно проверять срез на nil перед проверкой его длины.
Например, в следующем фрагменте кода проверка на nil избыточна:
Этот код можно переписать, убрав из него проверку на nil:
9. Ненужные функциональные литералы
Если в теле функционального литерала нет ничего кроме обращения к единственной функции, то от этого литерала можно, без ущерба для возможностей программы, отказаться. Например:
Этот код можно улучшить, вынеся add из функционального литерала:
10. Использование единственного блока case в выражениях select
Выражения select используются при работе с каналами. Обычно они включают в себя несколько блоков case. Но в том случае, если речь идёт об обработке единственной операции, представленной единственным блоком case, использование выражения select оказывается избыточным. В подобной ситуации можно просто воспользоваться операциями отправки данных в канал или их получения из канала:
В выражении select может применяться блок default, код которого выполняется в том случае, если системе не удаётся подобрать подходящий блок case. Использование default позволяет создавать неблокирующие выражения select:
11. Параметр типа context.Context, который не является первым параметром функции, в которой используется этот параметр
Если функция имеет параметр типа context.Context, то ему обычно дают имя ctx, а при объявлении функции его следует ставить первым в списке параметров. Такой аргумент используется в Go-функциях достаточно часто, а подобные аргументы, с логической точки зрения, лучше размещать в начале или в конце списка аргументов. Почему?
Это помогает разработчикам не забывать об этих аргументах благодаря единообразному подходу к их использованию в различных функциях. Вариативные функции в Go объявляют с использованием конструкции вида elems ...Type, которая должна располагаться в конце списка их параметров. В результате рекомендуется делать параметр типа context.Context первым параметром функции. Подобные соглашения имеются и в других проектах, например, в среде Node.js первым параметром, который передают коллбэкам, принято делать объект ошибки.
// Не рекомендовано
for _ = range sequence
{
run()
}
x, _ := someMap[key]
_ = <-ch
// Рекомендовано
for range something
{
run()
}
x := someMap[key]
<-ch
for _, v := range sliceTwo {
sliceOne = append(sliceOne, v)
}
sliceOne = append(sliceOne, sliceTwo…)
ch = make(chan int, 0)
sl = make([]int, 1, 1)
ch = make(chan int)
sl = make([]int, 1)
const c = 0
ch = make(chan int, c) // Это — не антипаттерн
// Бесполезное выражение return, не рекомендовано
func alwaysPrintFoofoo() {
fmt.Println("foofoo")
return
}
// Рекомендовано
func alwaysPrintFoo() {
fmt.Println("foofoo")
}
// Не рекомендовано
switch s {
case 1:
fmt.Println("case one")
break
case 2:
fmt.Println("case two")
}
// Рекомендовано
switch s {
case 1:
fmt.Println("case one")
case 2:
fmt.Println("case two")
}
switch 2 {
case 1:
fmt.Print("1")
fallthrough
case 2:
fmt.Print("2")
fallthrough
case 3:
fmt.Print("3")
}
wg.Add(1)
// ...какой-то код
wg.Add(-1)
wg.Add(1)
// ... какой-то код
wg.Done()
if x != nil && len(x) != 0 {
// выполняем какие-то действия
}
if len(x) != 0 {
// выполняем какие-то действия
}
fn := func(x int, y int) int { return add(x, y) }
fn := add
// Не рекомендовано
select {
case x := <-ch:
fmt.Println(x)
}
// Рекомендовано
x := <-ch
fmt.Println(x)
select {
case x := <-ch:
fmt.Println(x)
default:
fmt.Println("default")
}
// Не рекомендовано
func badPatternFunc(k favContextKey, ctx context.Context) {
// выполняем какие-то действия
}
// Рекомендовано
func goodPatternFunc(ctx context.Context, k favContextKey) {
// выполняем какие-то действия
}
Как писать хороший код (источник)
В этом материале сделана попытка найти ответ на большой вопрос из вышеприведенного комикса. Самый простой способ писать хороший код заключается в том, чтобы не употреблять в своих программах так называемые «антипаттерны».