Re: Lua style guide ?

[Russell Haley <russ.haley@...>]

On Sun, Jun 11, 2017 at 11:10 PM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Martin once stated:
>> On 06/11/2017 04:15 PM, Sean Conner wrote:
>> >   For example, this function:
>> >
>> >     function encode(value,sref,stref)
>> >       local res = ""
>> >
>> >       if stref and not stref.SEEN then
>> >         res = TAG._stringref(nil,nil,stref)
>> >       end
>> >
>> >       return res .. __ENCODE_MAP[type(value)](value,sref,stref)
>> >     end
>> >
>> > such a tool could return:
>> >
>> >     --- Placeholder
>> >     -- @function encode
>> >     -- @param value
>> >     -- @param sref
>> >     -- @param stref
>> >     -- @return
>> >     function encode(value,sref,stref)
>> >     ...
>> >
>> >   -spc (I don't understand the full scope of this, so of course it must be
>> >     trivial! 8-P
>>
>> Hmm, as experiment I can create a breed of lua code formatter which
>> produces output with such autogenerated comments. But is there really
>> need for this?
>>
>> Function in Lua may be defined in three ways:
>>
>> 1. "local function <name> (<args>)" //<name> can't contain ":" syntel
>> 2. "function <name> (<args>)"
>> 3. "function (<args>)"
>
>   Actually, you have:
>
>         1. function <name>(<args>)
>         2. local function <name>(<args>)
>         3. function <name>.<name>(<args>) -- defined on a table
>         4. function <name>:<name>(<args>) -- also defined on a table
>         5. function (<args>) -- anonymous function
>
>> Most obscure case is (3). It is often used as expression for sort() or
>> gsub(). Do you have a good heuristic how do decide emit/not_emit header
>> for function, given annotated syntax tree of source?
>
>   As a first stab (and probably most useful) [1], just annotating style 1,
> with maybe an option for style 2, would do [2].  Furthermore, if you could
> determine if 2 was at the "global" level (that is, top level scope for a
> file) and only do those would again be better.
>
>> And by the way, are there good ways to test such formatter? Creating yet
>> another rock with name like "lcf.experiments" looks like a bad idea.
>
>   I'm not sure what you are asking here.

Github would be my go-to.

Russ

>   -spc (Hmm ... not so trival after all 8-P
>
> [1]     Just a gut feeling, no actual studies behind this.
>
> [2]     I did mention I didn't understand the full scope of this.
>