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?
These are some pretty useful questions. I don't mean to bikeshed, but I'd call them Best Practices. I believe style is more about presentation and your list is about convention and practices that, when consistently applied, create a set of reasonable expectations for how things work.
On style: i can't help but think of books and also the world of ConTeX and LaTeX. Imagine if people argued about what specific font to use or exactly which page layout was best for all projects. It would be nonsense.
In the world of software developers, we actually argue about whether or not it is better to use a space instead of a tab to indent code. If that is in the realm of debatable topics for software coding style, then it tells me that nobody is really that serious about the topic.
Little tiny programs and big giant projects will benefit from different styles. Functional programming might benefit from different formatting styles than OOP, and OOP written with tables might be better written in a style that is apart from OOP written with closures.
At bottom, I enjoy reading code with a thoughtful and consistent formatting style. When someone puts time into how their code looks on the screen, it's easy to spot and fun to follow, especially if Best Practices are followed.
-Andrew
