Re: Lua style guide ?

[Hisham <h@...>]

On 10 June 2017 at 01:18, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2017-06-10 2:10 GMT+02:00 Hisham <h@hisham.hm>:
>> On 8 June 2017 at 10:21, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>>> 2017-06-08 13:51 GMT+02:00 steve donovan <steve.j.donovan@gmail.com>:
>>>
>>>> Heh, but they had curly-braces to deal with, always a fine topic for
>>>> bikeshedding!
>>>
>>> Finally, the word emerges. I have been restraining myself, disciplining
>>> my fingers, choking it down, ever since this thread started, and there
>>> you go and just casually spit it out.
>>
>> I've come to dislike this word more and more over the years, as it's
>> way too often used as a way to shut down conversations, in the style
>> of Godwin's Law. For all the discussions on syntax we've had over the
>> years on lua-l, I think this one was one of the best ones, especially
>> since (a) it is focused on actual Lua syntax, which has a limited
>> scope (and not proposed inventions, for which not even the sky is the
>> limit), and (b) it is discussed for what it is: style. Style is
>> important, and while it's hard to get good discussions on style that
>> go beyond "mine is better than yours", once people get past that point
>> one can get some good insights on what makes people's sense of style
>> tick, what are their rationales and especially to revisit and
>> reevaluate one's own. I learned some good stuff while reading other
>> people's style guides and writing my own!
>
> My main beef is that despite the title, there has been almost no
> discussion of style (which means: among several ways of doing the
> same task, pick one and always do it like that); it's all been about
> prettyprinting: how many spaces, what about tabs. why not blank
> lines instead, etc. You can no more get people to agree on that
> than you can change their taste in music. A convention for indents
> is vital for Python, but  Lua is not Python.
>
> Put another way: if all that you are going to achieve is another
> program with exactly the same compilable code, it just looks nicer,
> fro a certain meaning of 'nice', I don't care what you did, I'm going
> to run your code through my in-house reformatter anyway.
>
> Non-trivial style means doing things in a certain way, every time,
> so that others on the project (or yourself, next year) feel at home
> with the code. Things like:
>
> 1. What will our 'require' return? A function? A table? A userdata?
> 2. Do we locally cache predefined globals?
> 3. How do we code sentinel objects (i.e values that like nil are
> guaranteed not to be equal to anything else)?
> 4. Do we make big do ... end blocks in our code in order to
> restrict the scope of locals?
> 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)?
> 6. Do we consciously conform to ldoc rules for comments?

Did you follow the links for the various style guides posted? They
address these things. Mine specifically answers questions 1, 5 and 6.

For the other ones, my answers as far as the LuaRocks project goes
(because not every project has the same constraints) is:

2. No. This kind of micro-optimization should be avoided unless shown
to be measurably necessary (which is not the case in the LuaRocks
command-line tool).
3. In the rare event I needed this, I simply declared it as {}
4. No. Use short functions and modules.

-- Hisham