Контроль консистентности кода в Go

[quasilyte]

Если брать в расчёт стандартную библиотеку и произвольные функции, которые могут выполнять одинаковые операции, список будет стремиться к бесконечности. :)

Обычно в строку всё же через string(b) приводят, линтеры типа gosimple на некоторые схожие конструкции предлагают более простые замены.

go-consistent скорее о тех случаях, когда не очевидно, какой из вариантов "правильный", поэтому ответ ищется внутри исходных кодов проекта.

[blind_oracle]

Кастинг byte в string и обратно в Go почти бесплатный, в отличии от вызова достаточно тяжелого fmt.

[powerman]

Так многим кажется на первый взгляд, но по факту, если не полениться, и проверить, иногда случаются сюрпризы. Были тесты, которые показывали, что в некоторых ситуациях и на некоторых версиях Go fmt.Sprintf оказывается быстрее, чем конвертация/конкатенация средствами языка.

[blind_oracle]

Я говорю про конкретный случай перевода string <-> []byte, а не «некоторые ситуации».
Не поленился и проверил:

$ 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 раз.

[KevlarBeaver]

Чем больше исходные коды программы выглядят так, будто их написал один человек, тем более они консистентны.

Так, это, надо вырабатывать best practices, составлять code conventions и обязывать разрабов следовать им. Разве этого недостаточно? Ну тогда введите ещё code review.

[quasilyte]

Так, это, надо вырабатывать best practices, составлять code conventions

go-namecheck верифицирует (некоторые) конвенции, чтобы не проверять глазками.

и обязывать разрабов следовать им.

Я бы предпочёл, чтобы как можно больше работы по незначительным вещам выполнялось автоматически или, хотя бы, детектировались программами.

Ну тогда введите ещё code review.

Code review это не отменяет. Тут как с линтерами. Они ревью не заменяют, но могут сильно помогать.

[yayashitoya]

gometalinter упомянутые утилиты известны?
Если нет — то надо.

[quasilyte]

Нет, в нём нет интеграций, да и сами утилиты совсем недавно появились.
Меня терзают некоторые сомнения насчёт запуска go-consistent вместе с другими проверками.

Лично я это писал для переодических уборок в коде, а не для постоянных проверок. Если на каждом ревью к такому придираться, может быть больше вреда, чем пользы. А править предупреждения go-consistent можно и автоматически, возможно сделаю даже флаг автоматического исправления, оно не должно ничего ломать, там как все альтернативы польностью эквивалентны (по крайней мере должны быть таковыми).

[kyak]

Поделюсь с вами хорошим словом — «единообразие». Написали бы «единообразие исходного кода» — и вот уже не надо вводить определение «консистентности».

[tendium]

Слово consistency имеет несколько иное значение, нежели «единообразие». Я бы выделил такие (в данном контексте): последовательность и согласованность. Но в речи программистов и «околопрограммистов» слово консистентность, имхо, быстрее указывает на то, что имеется в виду.

[yayashitoya]

Но в речи программистов и «околопрограммистов» слово консистентность, имхо, быстрее указывает на то, что имеется в виду.

Про базы данных — да.
Про исходный код — это вы сами придумали, это не устоявшийся термин.

[tendium]

Все термины когда-то были неустоявшимися. ;)

[gnomeby]

Я бы предложил добавить проверку на соответствие типов переменных к их названию. Пример:
* Error бывает только у переменных начинающихся с err
* ok бывает только bool
* общая статистика по тому как имена и типы друг к другу относятся