Short vs. long variable declarations

[Will Faught]

Which do you default to? I see a lot of code using short decls in most cases, and only using long decls with no initialization where the zero value is needed. It seems to me that long decls should be the default declaration used because short decls are context-sensitive. That is, you have no idea what this is doing:

x, y := z()

It might be declaring x and y, or just x, or just y. This can lead to copy/paste and variable shadowing errors. Long declarations don't have those problems. As a bonus, the long declaration syntax matches those for consts and types:

const c = ... 

type t ... 

var x = ...

So I use long declarations unless I need to declare a new variable in combination with assigning to an existing variable, like reusing an err variable:

var w, err = x()

y, err := z()

The short declaration draws attention to the fact that something clever is going on.

What do you think? I'm looking for pragmatic reasons for or against.

[Shawn Milochik]

Here's a good discussion about it:

https://groups.google.com/d/msg/golang-nuts/J9QeizedpuI/ECifbR0YGcsJ

TL;DR: scope

[Tyler Compton]

While theoretically, I agree with your argument against using the short variable declaration pattern, I've personally found that in practice it isn't an issue. I think that if this is something you run into often, it might suggest that you're letting too many variables into your scope, whether that means having too many generically named global variables or being inside too large a function.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shawn Milochik]

On Fri, Jan 27, 2017 at 6:00 PM, Tyler Compton <xav...@gmail.com> wrote:

While theoretically, I agree with your argument against using the short variable declaration pattern, I've personally found that in practice it isn't an issue. I think that if this is something you run into often, it might suggest that you're letting too many variables into your scope, whether that means having too many generically named global variables or being inside too large a function.

On Fri, Jan 27, 2017, 11:57 AM Shawn Milochik <shawn...@gmail.com> wrote:

Here's a good discussion about it:

https://groups.google.com/d/msg/golang-nuts/J9QeizedpuI/ECifbR0YGcsJ

TL;DR: scope

I'm not making an argument against them, and use them all the time. The original post in that thread was from years ago, when I was new to Go and steeped in the ways of Python. :o)

 

[Will Faught]

This seems to be a discussion about short variable names. What's the connection?

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/222uOfTmd0U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Will Faught]

Variable shadowing is rarely, if ever, a problem for me too; but what about for newcomers?

I think my copy/paste point stands, though; everyone has those problems, at least occasionally.

You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/222uOfTmd0U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Marvin Renich]

* Will Faught <will....@gmail.com> [170127 21:58]:

> Variable shadowing is rarely, if ever, a problem for me too; but what about
> for newcomers?
>
> I think my copy/paste point stands, though; everyone has those problems, at
> least occasionally.

I agree with you. See my earlier post for my reasoning:

https://groups.google.com/d/msg/golang-nuts/an7f4o-1cjY/UxexDsuDAwAJ

In short, in the multiple assignment case, «var» instead of «:=» adds
one line of code, but it eliminates ambiguity completely. In

a, b, c := Foo(d)

what is the cost to every reader of your code to determine which of a,
b, and c are being shadowed? Look through the entire scope for three
different variable names, at least one of which you are guaranteed to
*not* find, which means you absolutely need to read all the way back to
the beginning of the scope (and hope you don't miss an earlier
declaration which might by var or might be :=). In

var b SomeType
a, b, c = Foo(d)

what is the cost? Zero!

In the single assignment case, := saves only three characters. There
may be no ambiguity about which variables are being shadowed, but for
those of us who have experience with a variety of languages, := has
different meanings in different languages; var a = Foo() is clearly a
declaration, but there is significant cognitive load to recognize that
a := Foo() is a declaration, not a simple assignment or something else.
This cognitive load may not apply equally to everyone, but it does apply
to some people, so if anyone else will read your code, be polite and
make it equally readable for everyone: use the long declaration (which
really isn't long).

...Marvin