When is multiple assignment good style?

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

When is multiple assignment good style?

Dirk Laurie-2
Which of the following uses is in your opinion good style?

- local a,r,k,n = 10000.0, 5.2, 12, 5   -- initializing locals
- local a,r,k,n = 10000,0                    -- initializing only some
- local sort, open, min = table.sort, io.open, math.min  -- caching
library functions
- a,b,c = b,c,a                             -- permuting values
- x,t = x+dx, t+dt                        -- updating related values
- name,cases,fct = "John", {2,5,6},myfunc   -- defining unrelated values
- local a1,a2,[[...,]]a256 = 1,1,[[...,]1  -- trying to crash the interpreter

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Daurnimator
On 13 March 2017 at 18:20, Dirk Laurie <[hidden email]> wrote:
> Which of the following uses is in your opinion good style?
>
> - local a,r,k,n = 10000.0, 5.2, 12, 5   -- initializing locals

Only if they are related constants (e.g. constants from a known
formula if you're implementing an algorithm described in a paper)

> - local a,r,k,n = 10000,0                    -- initializing only some

Rarely

> - local sort, open, min = table.sort, io.open, math.min  -- caching
> library functions

I used to do this, but not any more.

> - a,b,c = b,c,a                             -- permuting values

Yes.

> - x,t = x+dx, t+dt                        -- updating related values

Usually only for *very* related values (e.g. x,y for a point)

> - name,cases,fct = "John", {2,5,6},myfunc   -- defining unrelated values

No.

> - local a1,a2,[[...,]]a256 = 1,1,[[...,]1  -- trying to crash the interpreter

This style can be useful for larger vectors.

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Alexey Melnichuk-2
In reply to this post by Dirk Laurie-2
Здравствуйте, Dirk.

Вы писали 13 марта 2017 г., 10:20:52:

> Which of the following uses is in your opinion good style?

> - local a,r,k,n = 10000.0, 5.2, 12, 5   -- initializing locals
> - local a,r,k,n = 10000,0                    -- initializing only some
> - local sort, open, min = table.sort, io.open, math.min  -- caching
> library functions
> - a,b,c = b,c,a                             -- permuting values
> - x,t = x+dx, t+dt                        -- updating related values
> - name,cases,fct = "John", {2,5,6},myfunc   -- defining unrelated values
> - local a1,a2,[[...,]]a256 = 1,1,[[...,]1  -- trying to crash the interpreter


I also use

- a,b,c,d = nil -- assign nil to multiple values

--
С уважением,
 Alexey                          mailto:[hidden email]


---
Это сообщение проверено на вирусы антивирусом Avast.
https://www.avast.com/antivirus


Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Sean Conner
In reply to this post by Dirk Laurie-2
It was thus said that the Great Dirk Laurie once stated:

> Which of the following uses is in your opinion good style?
>
> - local a,r,k,n = 10000.0, 5.2, 12, 5   -- initializing locals
> - local a,r,k,n = 10000,0                    -- initializing only some
> - local sort, open, min = table.sort, io.open, math.min  -- caching
> library functions
> - a,b,c = b,c,a                             -- permuting values
> - x,t = x+dx, t+dt                        -- updating related values
> - name,cases,fct = "John", {2,5,6},myfunc   -- defining unrelated values
> - local a1,a2,[[...,]]a256 = 1,1,[[...,]1  -- trying to crash the interpreter

  I only use multiple assignments in one line for two cases:

        permuting values (and then, it's usually only a swap of two values)
        when a function returns more than one value

For everything else, I tend to use one variable per line.  I tend to like
vertical code layouts (it comes from years of assembly language
programming).

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Paul E. Merrell, J.D.
Add a couple of obvious ones that I use a lot:

* When host program's API method has multiple returns, e.g.,

  int, string Nc_GUI_SelectionDlg( string strWindowTitle[, string
strItem1, string strItem2, ...])

Returns the index of the menu item selected and the text of that menu
item. Index is -1 if user canceled.

* Conditional permutations, e.g., for character offset spans:

   if nFrom > nTo then
      nFrom, nTo = nTo, nFrom
   end

Best regards,

Paul
Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Viacheslav Usov
In reply to this post by Dirk Laurie-2
On Mon, Mar 13, 2017 at 8:20 AM, Dirk Laurie <[hidden email]> wrote:

> - local a,r,k,n = 10000.0, 5.2, 12, 5   -- initializing locals
> - local a,r,k,n = 10000,0                    -- initializing only some
> - local sort, open, min = table.sort, io.open, math.min  -- caching library functions

The above reminds of an email I sent to my colleagues a couple of weeks ago, which said:

local a, b, c, d, e, f, g, h, I, j = k, l, m, n, o, o, q, r, s

One will have to count variables above to figure out what is assigned to what. It is not immediately obvious that the list on the right is shorter than the left-hand list.

(end)

Your first example, with four variables, is already problematic in the sense that while it can be dealt with comfortably, I still have to pause for a brief moment and think along these lines: "5.2, being the second from the left corresponds to r, the second from the left". This flashes through my brain very quickly and so it is almost effortless, but still it means this is less comfortable than the third example, which does not require that sort of reasoning, where I can just see what is assigned to what. So I would say more than three values should be avoided.

That also applies to these:

> - a,b,c = b,c,a                             -- permuting values
> - x,t = x+dx, t+dt                        -- updating related values

where, while the multi-assignment style is clearly beneficial for clarity, one ought to stay within reason (which you did).

The rest of your examples is nonsensical either in style or in function.

Cheers,
V.

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Tim Hill
In reply to this post by Sean Conner

> On Mar 13, 2017, at 1:35 AM, Sean Conner <[hidden email]> wrote:
>
>  I only use multiple assignments in one line for two cases:
>
> permuting values (and then, it's usually only a swap of two values)
> when a function returns more than one value
>
> For everything else, I tend to use one variable per line.  I tend to like
> vertical code layouts (it comes from years of assembly language
> programming).
>

Interesting, because I like multiple assignment to get just the opposite effect (also after many years of assembly coding). Given that the more of my code I can see on the screen at once, the more I like it, I tend to try to use a more horizontal style. However, I try to avoid piling up too many assignments (3-4 max), and only when the RHS expressions are simple.

Also,
its
often
easier
to
read
code
horizontally.

Another case is when a few local control variables are being setup for some following block of code. I like that they are grouped together to essentially say “setup state for the following code”.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Coda Highland
On Mon, Mar 13, 2017 at 9:41 AM, Tim Hill <[hidden email]> wrote:

>
>> On Mar 13, 2017, at 1:35 AM, Sean Conner <[hidden email]> wrote:
>>
>>  I only use multiple assignments in one line for two cases:
>>
>>       permuting values (and then, it's usually only a swap of two values)
>>       when a function returns more than one value
>>
>> For everything else, I tend to use one variable per line.  I tend to like
>> vertical code layouts (it comes from years of assembly language
>> programming).
>>
>
> Interesting, because I like multiple assignment to get just the opposite effect (also after many years of assembly coding). Given that the more of my code I can see on the screen at once, the more I like it, I tend to try to use a more horizontal style. However, I try to avoid piling up too many assignments (3-4 max), and only when the RHS expressions are simple.
>
> Also,
> its
> often
> easier
> to
> read
> code
> horizontally.
>
> Another case is when a few local control variables are being setup for some following block of code. I like that they are grouped together to essentially say “setup state for the following code”.
>
> —Tim

I think there's a reasonable argument for
local a, b, c, d =
      e, f, g, h

This gives you some level of alignment between value and variable that
one-lining it doesn't, while being more compact than a series of
one-variable assignments.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Dirk Laurie-2
2017-03-13 18:59 GMT+02:00 Coda Highland <[hidden email]>:
> I think there's a reasonable argument for
> local a, b, c, d =
>       e, f, g, h
>
> This gives you some level of alignment between value and variable that
> one-lining it doesn't, while being more compact than a series of
> one-variable assignments.

I do something like this for caching functions from loaded modules.
(Looks better in fixed-width font.)

local trim,  intowords,  paragraphs,  concat,  decat,  condense,  weights
  = U.trim,U.intowords,U.paragraphs,U.concat,U.decat,U.condense,U.weights

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Hisham
In reply to this post by Coda Highland
On 13 March 2017 at 13:59, Coda Highland <[hidden email]> wrote:
> I think there's a reasonable argument for
> local a, b, c, d =
>       e, f, g, h
>
> This gives you some level of alignment between value and variable that
> one-lining it doesn't, while being more compact than a series of
> one-variable assignments.

I think this a case where the over-simplified example is misleading.
It looks pretty with `a, b, c` but in the real world with significant
names, this becomes a pain to maintain, and when we stuff too much in
a single line, diffs are harder to read.

Things always look good in tiny examples with single-letter variables.
It's why I think it's so disengenious to defend `t[#t+1] = v` as the
preferred idiom for appending to an array. It looks good with a
single-letter variable and five-line tutorial examples, but in the
real world we use nested tables. In the end,
`table.insert(my.nested[data], v)` is both more readable and avoids
repetition (i.e. it's one thing less to have a typo on, one thing less
to change, one thing less to get out of sync). Note how in a realistic
example the variable name dominates the statement.

Do I think `table.insert` is too long? Yes I do, I wouldn't mind
having a shorter idiom (many were proposed here over the years, most
of them were fine, but I'm not getting into them because we risk
delving into syntactic bikeshedding again, so let's avoid that).

Do I think it's worth it to add `local tinsert = table.insert` to
every program? No, because I hate having to guess which abbreviation
the module author used to write a shorter `table.insert` in their code
(I've even seen `local append = table.insert` in the wild!). And then
again, the abbreviation doesn't gain us much: being comfortable to
read is more important than being comfortable to write, but being easy
to maintain is just as important if not more. (And before someone
mentions, the performance gains for localizing such variables are
overstated; done at the top of modules they become upvalues and not
true locals; and most of the modules I've seen doing this are far from
being aimed at performance-intensive tasks that would warrant this
kind of micro-optimization).

Back to the original topic of assignment style, I'm 100% with
Daurnimator in his assessment of Dirk's original post.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Nagaev Boris
On Thu, Mar 16, 2017 at 2:09 AM, Hisham <[hidden email]> wrote:
> (I've even seen `local append = table.insert` in the wild!).

It is not very surprising, because Go, Swift and Python call this
thing "append" (well, Go's append returns new value of a slice, so it
is slightly different). I don't like the fact that different words are
used to call this in languages: we already have push_back (C++), add
(Java, Javascript, C#), append (Python, Go, Swift), push (Perl, Rust),
array_push (PHP).

--
Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Francisco Olarte
On Thu, Mar 16, 2017 at 3:31 AM, Nagaev Boris <[hidden email]> wrote:
> On Thu, Mar 16, 2017 at 2:09 AM, Hisham <[hidden email]> wrote:
>> (I've even seen `local append = table.insert` in the wild!).
>
> It is not very surprising, because Go, Swift and Python call this
> thing "append"

I'm not familiar with go or swift, but I'd like to point Pyhton calls
it INSERT. The difference is the index is not optional and it has
another function called append which does insert-at-end ( to be
expected in a system where you have lists with a defined length
separated from mappings ).
...
> we already have push_back (C++),

C++ has, i.e. in vector, INSERT ( and push_back too )

> add
> (Java, Javascript, C#), append (Python, Go, Swift), push (Perl, Rust),
> array_push (PHP).

This are ( more or less ) variations of Python's append. The thing is
lua does NOT have append(at end, and generally amortized constant time
in many languages), you have to do it using generic insert(at any
position, including end, amortized constant time in many of those
languages but, IIRC, not in lua ( unless you are caching the length,
which I'll consider cheating  ))

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Chris Jones
In reply to this post by Hisham
Hey

On 16 March 2017 at 02:09, Hisham <[hidden email]> wrote:
Do I think `table.insert` is too long? Yes I do, I wouldn't mind
having a shorter idiom (many were proposed here over the years, most
of them were fine, but I'm not getting into them because we risk
delving into syntactic bikeshedding again, so let's avoid that).

I've always been curious what the reasoning is for not having all of the table functions, as methods on table objects.
 
Do I think it's worth it to add `local tinsert = table.insert` to
every program? No, because I hate having to guess which abbreviation
the module author used to write a shorter `table.insert` in their code

Yes, a thousand times this. I've accepted far too much code into Hammerspoon from people who know Lua better than I do, with this stuff in.

Combined with the apparent allergy to whitespace that many Lua coders have, it makes for code that is excruciatingly hard to read/debug!

--
Cheers,

Chris
Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

steve donovan
On Thu, Mar 16, 2017 at 1:52 PM, Chris Jones <[hidden email]> wrote:
> I've always been curious what the reasoning is for not having all of the
> table functions, as methods on table objects.

I suppose it's because tables start out life clean, without metatables
or identity. It's easy enough to give them a metatable with __index
pointing to table with a custom constructor like T{...}.

> Yes, a thousand times this. I've accepted far too much code into Hammerspoon

I think I'm a sinner then - because I have a compulsion to rename
table.insert as append!  Mostly because the word 'insert' sets up an
argument in my head ;)

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Francisco Olarte
Steve:

On Thu, Mar 16, 2017 at 1:39 PM, steve donovan
<[hidden email]> wrote:
> I think I'm a sinner then - because I have a compulsion to rename
> table.insert as append!  Mostly because the word 'insert' sets up an
> argument in my head ;)

I hope you just alias ( keep the insert name ), because otherwise when
you need "table.insert(list, 1, new_head)" append gets really ugly.

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

steve donovan
On Thu, Mar 16, 2017 at 2:44 PM, Francisco Olarte
<[hidden email]> wrote:
> I hope you just alias ( keep the insert name ), because otherwise when
> you need "table.insert(list, 1, new_head)" append gets really ugly.

Well then I would alias to insert, because it's not an append ;)

Not defending the practice, it's just what I tend to do.

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Soni "They/Them" L.
In reply to this post by Chris Jones


On 16/03/17 08:52 AM, Chris Jones wrote:

> Hey
>
> On 16 March 2017 at 02:09, Hisham <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     Do I think `table.insert` is too long? Yes I do, I wouldn't mind
>     having a shorter idiom (many were proposed here over the years, most
>     of them were fine, but I'm not getting into them because we risk
>     delving into syntactic bikeshedding again, so let's avoid that).
>
>
> I've always been curious what the reasoning is for not having all of
> the table functions, as methods on table objects.
>
>     Do I think it's worth it to add `local tinsert = table.insert` to
>     every program? No, because I hate having to guess which abbreviation
>     the module author used to write a shorter `table.insert` in their code
>
>
> Yes, a thousand times this. I've accepted far too much code into
> Hammerspoon from people who know Lua better than I do, with this stuff in.

I do `local tinsert = table.insert` for performance.

>
> Combined with the apparent allergy to whitespace that many Lua coders
> have, it makes for code that is excruciatingly hard to read/debug!
>
> --
> Cheers,
>
> Chris

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Francisco Olarte
In reply to this post by steve donovan
Steve:

On Thu, Mar 16, 2017 at 1:53 PM, steve donovan
<[hidden email]> wrote:
> On Thu, Mar 16, 2017 at 2:44 PM, Francisco Olarte
> <[hidden email]> wrote:
>> I hope you just alias ( keep the insert name ), because otherwise when
>> you need "table.insert(list, 1, new_head)" append gets really ugly.
> Well then I would alias to insert, because it's not an append ;)

Nice, I asked because I always read rename as rename(3), not as link(3) .

> Not defending the practice, it's just what I tend to do.

No, the practice is fine for me. In fact I usually have
shift/unshift/push/pop/splice in my tables ( too much perl in the last
25 years ).

I find insert behaviour in lua confusing, so I sometimes alias it to
push ( when not using may table module ) ( I tend to assume insert is
making room and defaults to start, do not know why, for default at end
I prefer Java name, add ).

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Eike Decker
Slightly OT but on topic of how to improve multiple assignments: 
Has anyone ever wished for something like

local sub, gmatch, match load string
-- where load is a keyword that is syntactic sugar for 'local sub, gmatch, match = string.sub, string.gmatch, string.match'
Reply | Threaded
Open this post in threaded view
|

Re: When is multiple assignment good style?

Nagaev Boris
On Thu, Mar 16, 2017 at 1:21 PM, Eike Decker <[hidden email]> wrote:
> Slightly OT but on topic of how to improve multiple assignments:
> Has anyone ever wished for something like
>
> local sub, gmatch, match load string
> -- where load is a keyword that is syntactic sugar for 'local sub, gmatch,
> match = string.sub, string.gmatch, string.match'

Take a look at http://www.freelists.org/post/luajit/local-in-syntax,24
and https://gist.github.com/meric/1883adb92044b75237bb0b42a63d5ed4
It provides hacks for the following syntaxes:

  local exp, log, sin, cos, tan within (math, 5)

and

  local import,
    asin, acos, atan from (math)

--
Best regards,
Boris Nagaev

12