lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




Le sam. 6 juil. 2019 à 02:48, Soni "They/Them" L. <fakedme@gmail.com> a écrit :


On 2019-07-05 9:28 p.m., Philippe Verdy wrote:
> Le mer. 3 juil. 2019 à 23:42, Soni "They/Them" L. <fakedme@gmail.com
> <mailto:fakedme@gmail.com>> a écrit :
>
>     If you indent with semicolons it'll never be an issue.
>
>
> May be, but what horror !
>
> And don't forget that programmers frequentlly have too long lines that
> they need to break
> So these lines will NOT start by semicolons after the indentation.

Indeed, as such you know exactly what's a continuation and what isn't.

But "indenting" with semicolons at start of lines are not solving that problem in Lua for what is not so much obvious: doing it would be intended to sovle the ambiguity, but in fact it does not at all: if there's a msising colon at start of line, some programmer way still think it is missing and would add one "to align the code" visually, when in fact it would break the code.

Really I prefer adding semicolons at end of lines (like in C/C++/Java) to explicitly "terminate" statements.

For continuation lines (after breaking long statements into multiple lines), it is extremely recommended to systematically indent the contituation lines by at one additional notch to give a visual hint that this is effectively a continuation and that no one should accidentally insert a statement in the middle of another one. But this does not change the recommandation of using semicolons at end of statements except after the "end" keyword where it is normally never needed: if you ever define an anonymous "function...end" that you want to use inside an _expression_ and followed immedialtey by a curryfied function call with a parameter, it is highly recommended to surroung the anonymous function by parentheses like "(function...end) parameter" but if that parameter is split on a separate line, it must be indented as well.

Lua's curryfied functions are the origin of these horrors, they are inconsistantly defined syntaxically, they are unnecessary syntaxic sugar causing all these problems.