Linter для Go для выявления переменных без явной инициализации?

Question

[duselguy]

Не нашёл линтер для Go для выявления переменных без явной инициализации. В чём причина, ведь есть линтеры для выявления неиспользуемых переменных.
P.S. "The variable holds zero-value for the type like zero for the number, false for Booleans, “” for strings, and nil for interface and reference type. So, there is no such concept of an uninitialized variable in Go language." - не ответ.

Comments

[Максим Федоров]

если прогнать все линтеры из набора go-linter
то точно ваш случай не зацепится? кажется, несколько линтеров пересеваются по похожим целям

[duselguy]

Максим Федоров,
Я просмотрел бегло описание всех линтеров в https://golangci-lint.run/usage/linters/ . Не нашёл ничего подходящего.
P.S. Не прогонял их.

Answer 1

[Roman K]

Зачем? Ну и если надо, этот "линтер" пишется одной

регуляркой

(\bvar [\s\w._+] [^=].*)|(.*?:= new\(.*)

за две минуты

Но всё равно непонятно — зачем? Есть куча типов, у которых неинициализированное значение — норма. strings.Builder, bytes.Buffer, sync.Mutex, массивы

Comments

[duselguy]

Спасибо,
1. Ваша регулярка не учитывает (по меньшей мере) условные операторы.
2. Зачем:
2.1. Чтобы не делать ошибки в процессе разработки.
2.2. Чтобы не выплеснуть ребёнка в процессе (долгой) жизни продукта, когда код будет модифицироваться.

[Roman K]

duselguy,

1. Ваша регулярка не учитывает (по меньшей мере) условные операторы.

Покажи пример, в котором можно создать переменную, не инициализировав её

2. Зачем:

Это был риторический вопрос с намёком на то, что ты не туда воюешь

[duselguy]

Покажи пример, в котором можно создать переменную, не инициализировав её

Это не возможно - см. мой текст на аглицком выше. Вопрос был про наличие/отсутствие дополнительного инструмента для избежания ошибок при разработке и модификации кода.

[Roman K]

duselguy, моя твоя не понимать. Я тебе даю регулярку, которая по моему мнению ловит все случаи объявления переменной без инициализации. По твоему мнению она ловит не все случаи. Я прошу тебя показать мне эти случаи, ты говоришь "Это не возможно". ???

[duselguy]

которая по моему мнению ловит все случаи объявления переменной без инициализации.

1) Не понял, да будет она проинициализирована в значение по умолчанию.
2) Пример:

Переменная по умолчанию <i>false</i>
... много кода
<b>явная инициализация</b> - установка в <b>true</b>
... много кода
if ,,, {
установка переменной в <i>true/false</i>
}
... много кода

Ваша регулярка будет выдавать OK после ошибочного удаления явной инициализации.
P.S. Сорри за форматирование.

[darst]

duselguy,

2.2. Чтобы не выплеснуть ребёнка в процессе (долгой) жизни продукта, когда код будет модифицироваться.

Для этого нужно писать unit тесты как минимум.

Answer 2

[Wirusnyy-chel]

Идея для проверки очень хорошая, но, судя по всему, такого литера ещё нет. Если найдёте или сами реализуете, пожалуйста отпишитесь.
Есть близкий по смыслу https://github.com/GaijinEntertainment/go-exhaustruct

Вариант с регулярной может помочь с реализацией необходимого вам поведения с помощью других линтеров.

Идея как это реализовать.
!! Warning похоже на небольшой костыль и сам это поведение не проверял!!
Линтеры:
1. Регулярка из ответа выше.
2. https://github.com/gordonklaus/ineffassign
3. Проверка на использование директивы nolint
Алгоритм:
1. Запрещаете неявную инициализации при помощи регулярки.
2. Если переменная должна быть инициализирована дальше в коде, ineffassing выдаст ошибку, поэтому добавляем директиву nolint. Если этой инициализации не будет (ошибка которую хотим поймать) - упадёт проверка на использование nolint

Comments

[duselguy]

Спасибо, но не осилил. Оставим это для следующего поколения, которое будет /censored/ с легаси кодом.

Answer 3

[khevse]

Частично покрывает ваш кейс для случаев

var x bool
switch y {
case 1:
 x:=true
....
}

print(x)

govet:
  check-shadowing: true
  enabled-all: true
  disable:
  - fieldalignment

источник

Comments

[duselguy]

khevse,

Очепятка (= vs :=) ?

package main

func main() {
	var x bool
	var y int
	switch y {
	case 1:
		x = true
	}
	print(x)
}

[khevse]

Иногда опечатка, но чаще - это переиспользование имён переменных при множественном присваивании значений результата некоторой функции.

Если немного усложнить предыдущий вариант

import "fmt"

func invoke() (int, error) {
	return 2, nil
}

func getX(src int) (int, error) {
	var x int
	switch src {
	case 1:
		x, err := invoke()
		if err != nil {
			return 0, err
		}
		fmt.Println(x)
	}

	return x, nil
}

func main() {
	x, err := getX(1)
	fmt.Println(x, err)
}
-----
2
0, nil

[duselguy]

khevse,
Ваш пример понятен, он соответствует #1: Unintended variable shadowing из книжки про 100 ошибок на Go.
В своём вопросе (и последнем примере) я имел в виду другое: наличие в компиляторе/линтере возможности обнаружения переменной с неявной инициализацией (zero-value), для которой нет явной инициализации (или явная инициализация внутри блока условного оператора).
P.S. Под явной инициализацией я подразумевал:
1. Явное присвоение начального значение переменной в операторе var.
2. Присвоение (=) в коде.
P.P.S. Исходный вопрос (плюсы и минусы концепции zero-value) был в большей степени риторическим.