Comments 14
Если брать в расчёт стандартную библиотеку и произвольные функции, которые могут выполнять одинаковые операции, список будет стремиться к бесконечности. :)
Обычно в строку всё же через string(b) приводят, линтеры типа gosimple на некоторые схожие конструкции предлагают более простые замены.
go-consistent скорее о тех случаях, когда не очевидно, какой из вариантов "правильный", поэтому ответ ищется внутри исходных кодов проекта.
Кастинг byte в string и обратно в Go почти бесплатный, в отличии от вызова достаточно тяжелого fmt.
Так многим кажется на первый взгляд, но по факту, если не полениться, и проверить, иногда случаются сюрпризы. Были тесты, которые показывали, что в некоторых ситуациях и на некоторых версиях Go fmt.Sprintf оказывается быстрее, чем конвертация/конкатенация средствами языка.
Не поленился и проверил:
$ cat test.go
package main
import (
"fmt"
"time"
)
func main() {
a := []byte{'h', 'e', 'l', 'l', 'o'}
t := time.Now()
for i := 0; i < 10000000; i++ {
b := string(a)
_ = b
}
fmt.Println(time.Since(t))
t = time.Now()
for i := 0; i < 10000000; i++ {
b := fmt.Sprintf("%s", a)
_ = b
}
fmt.Println(time.Since(t))
}
$ go run test.go
45.67577ms
1.063794046s
Разница — в 20 раз.
Чем больше исходные коды программы выглядят так, будто их написал один человек, тем более они консистентны.
Так, это, надо вырабатывать best practices, составлять code conventions и обязывать разрабов следовать им. Разве этого недостаточно? Ну тогда введите ещё code review.
Так, это, надо вырабатывать best practices, составлять code conventions
go-namecheck верифицирует (некоторые) конвенции, чтобы не проверять глазками.
и обязывать разрабов следовать им.
Я бы предпочёл, чтобы как можно больше работы по незначительным вещам выполнялось автоматически или, хотя бы, детектировались программами.
Ну тогда введите ещё code review.
Code review это не отменяет. Тут как с линтерами. Они ревью не заменяют, но могут сильно помогать.
Если нет — то надо.
Нет, в нём нет интеграций, да и сами утилиты совсем недавно появились.
Меня терзают некоторые сомнения насчёт запуска go-consistent вместе с другими проверками.
Лично я это писал для переодических уборок в коде, а не для постоянных проверок. Если на каждом ревью к такому придираться, может быть больше вреда, чем пользы. А править предупреждения go-consistent можно и автоматически, возможно сделаю даже флаг автоматического исправления, оно не должно ничего ломать, там как все альтернативы польностью эквивалентны (по крайней мере должны быть таковыми).
* Error бывает только у переменных начинающихся с err
* ok бывает только bool
* общая статистика по тому как имена и типы друг к другу относятся
Контроль консистентности кода в Go