Re: Lua style guide ?

[Dirk Laurie <dirk.laurie@...>]

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?