A tiny matter of style

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

A tiny matter of style

Dirk Laurie-2
When the right-hand side of an assignment is an anonymous function, I
nowadays put a semicolon after the final "end" to distinguish it from
other uses of  'end'. Do you like the idea or hate it?

Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Enrico Colombini
On 08-May-18 10:11, Dirk Laurie wrote:
> When the right-hand side of an assignment is an anonymous function, I
> nowadays put a semicolon after the final "end" to distinguish it from
> other uses of  'end'. Do you like the idea or hate it?

I don't use it, I prefer to just use indentation.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

dyngeccetor8
In reply to this post by Dirk Laurie-2
On 05/08/2018 11:11 AM, Dirk Laurie wrote:
> When the right-hand side of an assignment is an anonymous function, I
> nowadays put a semicolon after the final "end" to distinguish it from
> other uses of  'end'. Do you like the idea or hate it?

I don't use semicolons in Lua code.

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Soni "They/Them" L.
In reply to this post by Dirk Laurie-2


On 2018-05-08 05:11 AM, Dirk Laurie wrote:
> When the right-hand side of an assignment is an anonymous function, I
> nowadays put a semicolon after the final "end" to distinguish it from
> other uses of  'end'. Do you like the idea or hate it?
>

I only use semicolons when calling anonymous functions, e.g.
;(function() end)()

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Charles Heywood
I use Vim fold markers, so I'll have something like `function() -- {{{ anonymous: description here` and at the end of the function, `end -- }}}`, which means that I have both a marker for when a block ends as well as for when Vim should stop folding (which is kinda like "collapsing" for normal editors but a tad bit more powerful).

On Tue, May 8, 2018 at 7:05 AM Soni "They/Them" L. <[hidden email]> wrote:


On 2018-05-08 05:11 AM, Dirk Laurie wrote:
> When the right-hand side of an assignment is an anonymous function, I
> nowadays put a semicolon after the final "end" to distinguish it from
> other uses of  'end'. Do you like the idea or hate it?
>

I only use semicolons when calling anonymous functions, e.g.
;(function() end)()

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


--
--
Ryan | Charles <[hidden email]>
Software Developer / System Administrator
Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

David Favro
In reply to this post by Dirk Laurie-2
On May 8, 2018 8:11:26 AM UTC, Dirk Laurie <[hidden email]> wrote:
>When the right-hand side of an assignment is an anonymous function,
>I
>nowadays put a semicolon after the final "end" to distinguish it
>from
>other uses of  'end'. Do you like the idea or hate it?

I've done so for many years, but in my case it's for consistency: I terminate all assignment statements [1] with semicolons; an anonymous function is no different than any other expression to me (first class value).

Similarly, since "local function foo() end" is syntactic sugar for an assignment statement, I also terminate that with a semicolon.

[1] as well as standalone function-call statements.

-- David


Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Egor Skriptunoff-2
In reply to this post by Dirk Laurie-2
On Tue, May 8, 2018 at 11:11 AM, Dirk Laurie wrote:
When the right-hand side of an assignment is an anonymous function, I
nowadays put a semicolon after the final "end" to distinguish it from
other uses of  'end'. Do you like the idea or hate it?


Some programming languages (e.g PL/SQL) have distinct syntax for "end" depending on the statement:

if ... end if;
for k in 1..5 loop ... end loop;
case ... end case;
function FuncName ... end FuncName;

Do you want to achieve the same goal by appending a semicolon to "end"?
Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Lorenzo Donati-3
On 09/05/2018 18:24, Egor Skriptunoff wrote:

> On Tue, May 8, 2018 at 11:11 AM, Dirk Laurie wrote:
>
>> When the right-hand side of an assignment is an anonymous function, I
>> nowadays put a semicolon after the final "end" to distinguish it from
>> other uses of  'end'. Do you like the idea or hate it?
>>
>>
> Some programming languages (e.g PL/SQL) have distinct syntax for "end"
> depending on the statement:
>
> if ... end if;
> for k in 1..5 loop ... end loop;
> case ... end case;
> function FuncName ... end FuncName;
>

I often comment the end of scopes that span over about 15-20 lines,
especially when there are multiple nested scopes. For example

if ....
   for ...
    -- blah
   end -- for

   function MyFunc(....)
    -- more blah
   end -- function MyFunc
end -- if

You get the gist of it.
It helps a lot when debugging or refactoring code.


I wouldn't mind if Lua allowed an optional syntax for specifying what
"end" ends; optional but enforced if used, i.e. an error would be issued
if (say) "end for" didn't end a for structure.

I can't say if it would be too heavy for the compiler or if a nice
syntax could be devised that didn't render the grammar too complicated

For example:

end for         (ambiguous)
vs.
end for;
vs.
end ---for      (semantic comments?)
vs.
end ::for::     (fake label? ambiguous)
vs.
<choose your poison!>

Just rambling, not a well fleshed-out RFE anyway.

> Do you want to achieve the same goal by appending a semicolon to "end"?
>

Cheers!

-- Lorenzo

Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Sean Conner
It was thus said that the Great Lorenzo Donati once stated:

>
> I wouldn't mind if Lua allowed an optional syntax for specifying what
> "end" ends; optional but enforced if used, i.e. an error would be issued
> if (say) "end for" didn't end a for structure.
>
> I can't say if it would be too heavy for the compiler or if a nice
> syntax could be devised that didn't render the grammar too complicated
>
> For example:
>
> end for         (ambiguous)
> vs.
> end for;
> vs.
> end ---for      (semantic comments?)
> vs.
> end ::for::     (fake label? ambiguous)
> vs.
> <choose your poison!>

  Here are some other options:

        function() ... endfunction
        if ... then ... endif
        while ... do ... endwhile
        for ... do ... endfor
        do ... enddo -- hmm ...

Okay ...

        function() ... noitcnuf
        if ... then ... fi
        while ... do ... elihw
        for ... do ... rof
        do ... od --- hmm ...

  The do keyword is problematic.  Several constructs use it, but it can be
used on its own to intruduce a new lexical scope.

  In my own code, I don't think I've ever used a semicolon.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Lorenzo Donati-3
On 09/05/2018 21:44, Sean Conner wrote:

> It was thus said that the Great Lorenzo Donati once stated:
>>
>> I wouldn't mind if Lua allowed an optional syntax for specifying what
>> "end" ends; optional but enforced if used, i.e. an error would be issued
>> if (say) "end for" didn't end a for structure.
>>
>> I can't say if it would be too heavy for the compiler or if a nice
>> syntax could be devised that didn't render the grammar too complicated
>>
>> For example:
>>
>> end for         (ambiguous)
>> vs.
>> end for;
>> vs.
>> end ---for      (semantic comments?)
>> vs.
>> end ::for::     (fake label? ambiguous)
>> vs.
>> <choose your poison!>
>
>   Here are some other options:
>
> function() ... endfunction
> if ... then ... endif
> while ... do ... endwhile
> for ... do ... endfor
> do ... enddo -- hmm ...
>
> Okay ...
>
> function() ... noitcnuf
> if ... then ... fi
> while ... do ... elihw
> for ... do ... rof
> do ... od --- hmm ...
>
>   The do keyword is problematic.  Several constructs use it, but it can be
> used on its own to intruduce a new lexical scope.
>
>   In my own code, I don't think I've ever used a semicolon.
>
>   -spc
>
>
>
Interesting POVs.

I've never been a fan of languages that use reversing the keywords. They
make my "internal linguistic processor" go poof! and slow me down to a
crawl ( "'fi'?!? What the heck is 'fi'?!?" :-).

Although new keywords would fit the bill, I'd prefer something optional
and more "minimalist". In throwaway script I rarely bother to mark end
of scopes (even if quite lengthy), since I know I wouldn't be
maintaining that code beyond its initial purpose. So a plain "end" to
end all scopes is good and short (and in general you will have that
verbose "LaTeX environment feeling" with begin{myenv}/end{myenv} which
is tedious).

The headaches begin when I have an "old" (maybe 5 years) 1kLOC script
or, worse still, a 1kLOC+ library module where I put some "clever"
algorithm which once in a while needs some polishing or fixing (in the
last couple of years I did very little Lua coding, although I run Lua
scripts almost daily, since I have automated many common tasks using
scripts).

In this case having a way to mark scope ends that is enforced by the
compiler could be very nice.

Cheers!

-- Lorenzo





Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Albert Chan

> The headaches begin when I have an "old" (maybe 5 years) 1kLOC script or, worse still, a 1kLOC+ library module where I put some "clever" algorithm which once in a while needs some polishing or fixing (in the last couple of years I did very little Lua coding, although I run Lua scripts almost daily, since I have automated many common tasks using scripts).
>
> -- Lorenzo

Many editors nowadays show the scope in colors.
(Some can even collapse code chucks)

I would not bother with end scope comment.
Comment may go stale (when fixing code), which make it worse.

Proper indentation is much more important.
Example, Python does not even have the 'end' keyword.




Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

dyngeccetor8
In reply to this post by Sean Conner
On 05/09/2018 10:44 PM, Sean Conner wrote:

> It was thus said that the Great Lorenzo Donati once stated:
>> [...]
>> For example:
>>
>> end for         (ambiguous)
>> vs.
>> end for;
>> vs.
>> end ---for      (semantic comments?)
>> vs.
>> end ::for::     (fake label? ambiguous)
>> vs.
>> <choose your poison!>
>
>   Here are some other options:
>
>   function() ... endfunction
>   if ... then ... endif
>   while ... do ... endwhile
>   for ... do ... endfor
>   do ... enddo -- hmm ...
>
> Okay ...
>
>   function() ... noitcnuf
>   if ... then ... fi
>   while ... do ... elihw
>   for ... do ... rof
>   do ... od --- hmm ...
>

You can use [lua_code_formatter](search at github) as
transpiler for such stuff.

Just change input grammar for "function" definition and
"if", "for", "while", "do" constructs. Alternatively you
can modify it to produce "end  -- function" instead "end".

So this wishes may easily be implemented.

I don't think they have long-term perspectives. But it
may be fun to create private fork of language with
personal tweaks.

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Jonathan Goble
In reply to this post by Lorenzo Donati-3
On Wed, May 9, 2018 at 3:19 PM Lorenzo Donati <[hidden email]> wrote:
I wouldn't mind if Lua allowed an optional syntax for specifying what
"end" ends; optional but enforced if used, i.e. an error would be issued
if (say) "end for" didn't end a for structure.

I can't say if it would be too heavy for the compiler or if a nice
syntax could be devised that didn't render the grammar too complicated

For example:

end for         (ambiguous)
vs.
end for;
vs.
end ---for      (semantic comments?)
vs.
end ::for::     (fake label? ambiguous)
vs.
<choose your poison!>

Just rambling, not a well fleshed-out RFE anyway.

I'm indifferent on putting this in the language syntax, but a version of it using magic comments might be a good feature in a static analysis tool such as luacheck.
Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Russell Haley
In reply to this post by Dirk Laurie-2


On Tue, May 8, 2018 at 1:11 AM, Dirk Laurie <[hidden email]> wrote:
When the right-hand side of an assignment is an anonymous function, I
nowadays put a semicolon after the final "end" to distinguish it from
other uses of  'end'. Do you like the idea or hate it?


I think if I came across a large complex file where that style had been followed it would be an excellent clue when reading the code. But in an isolated example, the practice could be confusing, especially if someone is new.  

I'm sure I've seen something like that before, but I couldn't tell you where. As someone else has said, you will see no semicolons completing statements in my Lua code. 

Russ

Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Russell Haley
In reply to this post by Lorenzo Donati-3


On Wed, May 9, 2018 at 12:18 PM, Lorenzo Donati <[hidden email]> wrote:
On 09/05/2018 18:24, Egor Skriptunoff wrote:
On Tue, May 8, 2018 at 11:11 AM, Dirk Laurie wrote:

When the right-hand side of an assignment is an anonymous function, I
nowadays put a semicolon after the final "end" to distinguish it from
other uses of  'end'. Do you like the idea or hate it?


Some programming languages (e.g PL/SQL) have distinct syntax for "end"
depending on the statement:

if ... end if;
for k in 1..5 loop ... end loop;
case ... end case;
function FuncName ... end FuncName;


I often comment the end of scopes that span over about 15-20 lines, especially when there are multiple nested scopes. For example

if ....
  for ...
   -- blah
  end -- for

  function MyFunc(....)
   -- more blah
  end -- function MyFunc
end -- if

You get the gist of it.
It helps a lot when debugging or refactoring code.


I wouldn't mind if Lua allowed an optional syntax for specifying what "end" ends; optional but enforced if used, i.e. an error would be issued if (say) "end for" didn't end a for structure.
A file processor that marks up all the end statements for you would be more useful I think. It could also be used to see logic errors. Martin has an autoldoc project that would be a good fit for that kind of thing.


I can't say if it would be too heavy for the compiler or if a nice syntax could be devised that didn't render the grammar too complicated

For example:

end for         (ambiguous)
vs.
end for;
vs.
end ---for      (semantic comments?)
vs.
end ::for::     (fake label? ambiguous)
vs.
<choose your poison!>

Just rambling, not a well fleshed-out RFE anyway.

Do you want to achieve the same goal by appending a semicolon to "end"?


Cheers!

-- Lorenzo


Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Enrico Colombini
In reply to this post by Lorenzo Donati-3
On 09-May-18 21:18, Lorenzo Donati wrote:

> I often comment the end of scopes that span over about 15-20 lines,
> especially when there are multiple nested scopes. For example
>
> if ....
>    for ...
>     -- blah
>    end -- for
>
>    function MyFunc(....)
>     -- more blah
>    end -- function MyFunc
> end -- if
>
> You get the gist of it.
> It helps a lot when debugging or refactoring code.

I do the same (in any language), even if I usually prefer to comment
about what the function/block/loop actually did, rather than refer to
its opening instruction, e.g.:

   -- scan goblin list for culprit
   for g in ipairs(goblins) do
     ...
     ...
     ...
   end -- (goblin list scan)

And I too find reverse keywords confusing, I have to disentangle my
neurons afterwards.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Albert Chan
In reply to this post by Lorenzo Donati-3
> On May 9, 2018, at 3:18 PM, Lorenzo Donati <[hidden email]> wrote:
>
> I often comment the end of scopes that span over about 15-20 lines, especially when there are multiple nested scopes. For example
>
> if ....
>  for ...
>   -- blah
>  end -- for
>
>  function MyFunc(....)
>   -- more blah
>  end -- function MyFunc
> end -- if
>
> You get the gist of it.
> It helps a lot when debugging or refactoring code.
>

"Code Complete" recommend AGAINST end comment

Section Commenting Techniques:

Aside from a couple of special cases, endline comments have
conceptual problems and tend to be used for code that's too
complicated. They are also difficult to format and maintain.
Overall, they're best avoided

You don't need to use the technique [endline comment] for
short loops that aren't nested

When the nesting is deep or the loops are long, however, the
technique pays off ... [but] the best way is often to rewrite
the complicated code that requires tedious documentation.

--

 Deep nested loops can (and should) be avoided.

Section Taming Dangerously Deep Nesting
Section Controlling the Loops, How Long Should a Loop Be ?

* Make your loop short enough to view all at once
* Limit nesting to three levels
* Make long loops especially clear





Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

KHMan
On 5/10/2018 7:46 PM, Albert Chan wrote:

>> On May 9, 2018, at 3:18 PM, Lorenzo Donati wrote:
>>
>> I often comment the end of scopes that span over about 15-20 lines, especially when there are multiple nested scopes. For example
>>
>> if ....
>>   for ...
>>    -- blah
>>   end -- for
>>
>>   function MyFunc(....)
>>    -- more blah
>>   end -- function MyFunc
>> end -- if
>>
>> You get the gist of it.
>> It helps a lot when debugging or refactoring code.
>>
>
> "Code Complete" recommend AGAINST end comment

Sure, it's a useful guideline. But let's not zip ourselves into a
book-learning straitjacket.

I used a Bruce Lee quote on this kind of discussion once, let me
try it from a related angle. :-) In Chinese kungfu
stories/movies/series, what plot device does one often see? The
loyal disciple who diligently learns the forms but is rigid gets
beaten up. Who wins the day? The one who internalizes the forms,
then go formless...


> Section Commenting Techniques:
>
> Aside from a couple of special cases, endline comments have
> conceptual problems and tend to be used for code that's too
> complicated. They are also difficult to format and maintain.
> Overall, they're best avoided
>
> You don't need to use the technique [endline comment] for
> short loops that aren't nested
>
> When the nesting is deep or the loops are long, however, the
> technique pays off ... [but] the best way is often to rewrite
> the complicated code that requires tedious documentation.
>
> --
>
>   Deep nested loops can (and should) be avoided.
>
> Section Taming Dangerously Deep Nesting
> Section Controlling the Loops, How Long Should a Loop Be ?
>
> * Make your loop short enough to view all at once
> * Limit nesting to three levels
> * Make long loops especially clear


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia



Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Albert Chan
> On May 10, 2018, at 11:29 AM, KHMan <[hidden email]> wrote:
>
>> "Code Complete" recommend AGAINST end comment
>>
>> -- Albert
>
> Sure, it's a useful guideline. But let's not zip ourselves into a book-learning straitjacket.
>
> I used a Bruce Lee quote on this kind of discussion once, let me try it from a related angle. :-) In Chinese kungfu stories/movies/series, what plot device does one often see? The loyal disciple who diligently learns the forms but is rigid gets beaten up. Who wins the day? The one who internalizes the forms, then go formless...

Guideline(s) are needed because you might re-read the
code months later. DO NOT go  "Bruce Lee" on the code.

And, PLEASE, do not go "formless" !

:-)





Reply | Threaded
Open this post in threaded view
|

Re: A tiny matter of style

Coda Highland
On Thu, May 10, 2018 at 11:44 AM, Albert Chan <[hidden email]> wrote:

>> On May 10, 2018, at 11:29 AM, KHMan <[hidden email]> wrote:
>>
>>> "Code Complete" recommend AGAINST end comment
>>>
>>> -- Albert
>>
>> Sure, it's a useful guideline. But let's not zip ourselves into a book-learning straitjacket.
>>
>> I used a Bruce Lee quote on this kind of discussion once, let me try it from a related angle. :-) In Chinese kungfu stories/movies/series, what plot device does one often see? The loyal disciple who diligently learns the forms but is rigid gets beaten up. Who wins the day? The one who internalizes the forms, then go formless...
>
> Guideline(s) are needed because you might re-read the
> code months later. DO NOT go  "Bruce Lee" on the code.
>
> And, PLEASE, do not go "formless" !
>
> :-)

You, the programmer, are formless. The code has form, and you mold
yourself to fit what it needs.

/s/ Adam

12