Re: Lua style guide ?

[Daurnimator <quae@...>]

On 10 June 2017 at 14:18, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 1. What will our 'require' return? A function? A table? A userdata?

A table: I learnt this by trail and error when I eventually wanted to
add an extra function to what was meant to be a one-function-module
(thankfully I could keep backwards compat via __call).
With a table you can also add other metadata such as a VERSION field.
And you get a few other misc things by being a table, e.g. tracebacks
will be more informative due to how findfield works
https://www.lua.org/source/5.3/lauxlib.c.html#findfield

> 2. Do we locally cache predefined globals?

I used to, but not anymore unless there is a very tight loop: and then
I cache in a local, not an upvalue.
The other time you might see it is for compatability, e.g.
local unpack = table.unpack or unpack

> 3. How do we code sentinel objects (i.e values that like nil are
> guaranteed not to be equal to anything else)?

I have rarely needed this: usually you work around it with e.g. a length field.
However in the rare circumstance: use an empty table: {}

> 4. Do we make big do ... end blocks in our code in order to
> restrict the scope of locals?

Yes, if the initialisation of a local takes up more than one statement

> 5. Do we use some sort of Hungarian notation (i.e. CamelCase,
> quick_brown_fox etc) that advertises what the name will be
> used for)?

No!

> 6. Do we consciously conform to ldoc rules for comments?

No. IMO comments in code should explain why calculations are made in a
specific order, or caution about possibly unexpected side effects:
info that someone browsing the code might not realise at first glance.
Documentation is best kept in a separate file, otherwise you often end
up just re-writing the code implementation in english, rather than
explaining at the higher logical level what the function is for.