fixed declaration dependencies and other lint issues in code base

[varun06]

Another lint/vet fix that's backward compatible.

+--------+---------+---------------------------+-------+------+------+------+
| STATUS | ELAPSED |          PACKAGE          | COVER | PASS | FAIL | SKIP |
+--------+---------+---------------------------+-------+------+------+------+
| PASS   | 76.81s  | github.com/Shopify/sarama | 0.0%  |  446 |    0 |    1 |
+--------+---------+---------------------------+-------+------+------+------+

[d1egoaz]

not sure about this one:
https://play.golang.org/p/vdAdcwi2i09

func main() {
	a := []int32{}
	var b []int32
	
	fmt.Printf("a: %#v\n", a)
	fmt.Printf("b: %#v\n", b)
}

result:
a: []int32{}
b: []int32(nil)

[varun06]

hmm, yeah, that does changes semantics. but as far as I know, An empty slice can be represented by nil or an empty slice literal. The first approach is preferred as it does not lead to memory allocation. also tests are passing with changing to nil slice declaration. Let me know if that sounds good?

[varun06]

https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices

[d1egoaz]

also tests are passing with changing to nil slice declaration

not sure if we are in a position to trust in the tests 😅

have you tried this branch in a running app?

[d1egoaz]

I asked some folks, and they mentioned that before the variable was initialized to an empty array, with your change the array is now nil.

However, append will initialize the array internally

// The append built-in function appends elements to the end of a slice. If
// it has sufficient capacity, the destination is resliced to accommodate the
// new elements. If it does not, a new underlying array will be allocated.

https://play.golang.org/p/4EHaAlO5eIG

so, 🤞 it looks should work

[karmakaze]

Go makes 'zero-values' do the expected thing. For slices, append, len, cap, range all behave well.

[d1egoaz]

it'd be great if you can try this branch first on an existing app