Re: Spaghetti, macaroni or ravioli?

[Russell Haley <russ.haley@...>]

Sorry, somehow sent that last one without finishing the message:

If (boolean condition) Then
    (consequent)
Else
    (alternative)
End If

I agree with nobody. If the consequent and the alternative are both
single calls, I do it on one line.

    assert(type(self) == "table","open_database must be called using
the colon ':' notation. example: env:open_database('name',true)")
    if name == "" then name = nil end
    if create and not name then return nil, "Cannot create database
with a name of blank ('') or nil." end

It' more difficult to 'read' when you are reading to learn the code,
but I find it easier to 'read'  it when I am parsing the logic
visually. I know these are single logic blocks.

In some languages (and according to some of the handbook rules at
work) I try to only exit at the bottom of a function. That doesn't
really seem apply to Lua the way it does C# or C++ from what I can
tell, but I don't have a concrete reason why I feel that way. I
suppose I I try to exit early in Lua too.

Russ


On Wed, Aug 16, 2017 at 11:30 AM, nobody <nobody+lua-list@afra-berlin.de> wrote:
> On 2017-08-16 11:57, Etiene Dalcol wrote:
>>
>> I do it like in the first option.
>>
>> But I prefer doing this depending on the condition:
>>
>> if reverse_condition then return end
>> call_my_routine()
>
>
> On 2017-08-16 11:49, Dirk Laurie wrote:
>> Suppose your program has some very short actions in an if.
>>
>> if condition then call_my_routine() else return end
>
> Same here – I make my funs exit as early as possible if that fits in a
> line (or 2-3 at most).
>
> (I also generally fold short blocks that fit in <80 chars into the same
> line, adding two spaces around the block and separating statements by
> space-semicolon-space. I don't do that (and use the "downwards form")
> if there are "serious" side-effects / variable updates that one should
> be aware of.)
>
>
> Rationale for both: Once the code exists, I'll only re-read it to
>   (a) improve it / fix bugs, or
>   (b) understand _what_ it does (usually not _how_ it does that)
> and the way I format the code is directly structured around that.
>
> Early exits means I can read down (and ignore the sideways bits) to get
> a general idea of the structure & what happens. I can then zoom in on
> the relevant part and read that in full. If I need more context, I can
> read down and accumulate constraints from the side-branches, still
> ignoring their content (because it won't significantly affect code
> further down). Only very rarely do I have to actually read the full thing.
>
> (Combined with terse 1-line "section comments" (setup, traverse left,
> combine, …) that permit skipping even more of the code, I find that I
> can quickly navigate & patch even years-old code.  So this seems to work
> very well for me.)
>
> -- nobody
>