Spaghetti, macaroni or ravioli?

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

Spaghetti, macaroni or ravioli?

Dirk Laurie-2
Suppose your program has some very short actions in an if.

if condition then call_my_routine() else return end

Do you indent it as:

if condition then
   call_my_routine()
else
   return
end

or as

if condition
   then call_my_routine()
   else return
end
if condition
   then call_my_routine()
   else return
end

or not at all?
Reply | Threaded
Open this post in threaded view
|

Re: Spaghetti, macaroni or ravioli?

Etiene Dalcol
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()


2017-08-16 10:49 GMT+01:00 Dirk Laurie <[hidden email]>:
Suppose your program has some very short actions in an if.

if condition then call_my_routine() else return end

Do you indent it as:

if condition then
   call_my_routine()
else
   return
end

or as

if condition
   then call_my_routine()
   else return
end
if condition
   then call_my_routine()
   else return
end

or not at all?



--
Etiene Dalcol

Software Engineer @ Red Badger 
Lua Space http://lua.space
LuaConf http://luaconf.com

Reply | Threaded
Open this post in threaded view
|

Re: Spaghetti, macaroni or ravioli?

Frank Kastenholz-2
In reply to this post by Dirk Laurie-2
Hi

The 2 primary rules for indentation that I use are
1 follow whatever the style is that already exists as
2 always indent the same way

This reduces the amount of interpretation and thinking needed by the next person to read the code

So I would always indent as:

> if condition then
>    call_my_routine()
> else
>    return
> end

And, as was suggested, I'd probably recast as

if ~condition then
    return
end
call_my_routine()

Frank



Reply | Threaded
Open this post in threaded view
|

Re: Spaghetti, macaroni or ravioli?

Francisco Olarte
Hi:

On Wed, Aug 16, 2017 at 12:17 PM, Frank Kastenholz
<[hidden email]> wrote:
> The 2 primary rules for indentation that I use are
> 1 follow whatever the style is that already exists as
> 2 always indent the same way
> This reduces the amount of interpretation and thinking needed by the next person to read the code

Whish many times happens to be your older self.

> So I would always indent as:
>> if condition then
>>    call_my_routine()
>> else
>>    return
>> end
> And, as was suggested, I'd probably recast as
> if ~condition then
>     return
> end
> call_my_routine()

I've found that the second style is easy to reparse when there is more
code following, and teh indentation-saving is a nice to have, but when
it is alone, i.e.,

do -- or if, or for, or whatever block construct
  if condition then
    call_my_routine()
  else
    return
  end
end

This version is easier (for me) to read.

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

Re: Spaghetti, macaroni or ravioli?

Martin
In reply to this post by Dirk Laurie-2

On 08/16/2017 10:49 AM, Dirk Laurie wrote:

> Suppose your program has some very short actions in an if.
>
> if condition then call_my_routine() else return end
>
> Do you indent it as:
>
> if condition then
>    call_my_routine()
> else
>    return
> end
> > [...]

I always start any statement from clean line.

local obj = {
  dummy = function() end,
  get = function(self)
    return self.dummy
  end,
}

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: Spaghetti, macaroni or ravioli?

Enrico Colombini
In reply to this post by Dirk Laurie-2
On 16-Aug-17 11:49, Dirk Laurie wrote:
> if condition then call_my_routine() else return end
>
> Do you indent it as:
>
> if condition then
>     call_my_routine()
> else
>     return
> end

Usually the latter one.
Rarely the one-liner above, but only for situations involving neither
function calls nor 'return' statements, i.e. when it is basically a form
of ternary operator.

As an aside: I try to avoid using 'return' in the middle of a function,
unless it is really needed for efficiency or for readability. I like to
be able to easily follow the execution flow when reading the code.
When I have to use 'return' I mark it with a special comment, such as:

  if condition then
      return --> exit
  end

and a blank line just below, to make it stand out.
I got this habit after reading "Structured programming with Pascal"
[Wirth]. It helped a lot with the assembly code I used to write at the
time... and proved useful for all languages I learned later.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Spaghetti, macaroni or ravioli?

nobody
In reply to this post by Etiene Dalcol
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

Reply | Threaded
Open this post in threaded view
|

Re: Spaghetti, macaroni or ravioli?

Oliver Kroth
In reply to this post by Dirk Laurie-2


Am 16.08.2017 um 11:49 schrieb Dirk Laurie:

> Suppose your program has some very short actions in an if.
>
> if condition then call_my_routine() else return end
>
> Do you indent it as:
>
> if condition then
>    call_my_routine()
> else
>    return
> end
>
> or as
>
> if condition
>    then call_my_routine()
>    else return
> end
> if condition
>    then call_my_routine()
>    else return
> end
>
> or not at all?
First option.

Additionally, I tend to put the shorter execution into the then part; so
it may read as :

if not condition then
     return
else
     call_my_routine()
     and some more
     lenghty
     stuff
end

As the return is very short, I tend to put it in one line:

if condition then return end

remaining
lengthy
process


Here a real-world example that tests conditions one by one and
immediately pops out on first matching:

function Analysis.ShortRingRate( rule, cdr, params )
     if not cdr.ddi or cdr.answered then return "n/a" end
     if cdr.ended - cdr.started >= params.max then return "too long" end
     if increment( CallsToDDI, cdr.ddi, params.wndw ) >1 then return
"same DDI" end
     if increment( rule, "count", params.wndw ) < params.warn then
return "need more" end

     email.send{ body="WarnShortRingRate", cdr=cdr, rule=rule,
params=params }
     return true
end



--
Oliver

Reply | Threaded
Open this post in threaded view
|

Re: Spaghetti, macaroni or ravioli?

Russell Haley
In reply to this post by nobody
On Wed, Aug 16, 2017 at 11:30 AM, nobody <[hidden email]> 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

I agree with nobody:

Reply | Threaded
Open this post in threaded view
|

Re: Spaghetti, macaroni or ravioli?

Russell Haley
In reply to this post by nobody
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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Spaghetti, macaroni or ravioli?

Rena
In reply to this post by Dirk Laurie-2
I usually do:

if condition then call_my_routine() else return end
if the resulting line is short, or:

if condition then
   call_my_routine()
else
   return
end
If it doesn't fit nicely in one line (usually because the body is more than one statement). However when the body is a single statement but doesn't fit on a line (because the condition is long), I sometimes do:
if condition
   then call_my_routine()
   else return
end
especially if it's several elif with complex conditions, eg:

if complex_condition_1
then do_thing_1
elif complex_condition_2
then do_thing_2
else return
end

What's most important is that the code is readable and not hideous to look at, rather than sticking strictly to one style at all times.

Reply | Threaded
Open this post in threaded view
|

Re: Spaghetti, macaroni or ravioli?

Enrico Colombini
On 16-Aug-17 22:22, Rena wrote:
> What's most important is that the code is readable and not hideous to
> look at, rather than sticking strictly to one style at all times.

Same here.

--
   Enrico