When is nesting good or neutral?

I was reading this post...

Please don't nest promises

Basti Ortiz ・ Jan 6 '20

#javascript #node #programming #tips

And I think we can generally agree on the idea here.

It got me wondering where nesting isn't bad, because in a lot of situations, nesting is a problem.

Is nesting in markdown a smell in and of itself?

<section>
  <div>
    <div>
      <div>
        ...

Is this good or neutral or is it something to be avoided when possible?

Is nesting conditional logic always bad, or are there situations where it's more helpful?

This is broad and abstract, so feel free to take it in any direction.

Comments

[@racascou]

There are situations where nesting is necessary, in all other you will do better with a flat solution.

[Jon Bristow]

Nesting conditional logic is not always bad.

Nesting promises is always less clear than it could be.

Consider:

• alpha takes a url and returns a promise of an http response.
• beta takes a url, calls alpha, and returns the promise of some heavy async calculation of an http response.

Versus in un-nested:

• alpha takes a url and returns a promise of an http response.
• beta takes a http response and returns a promise of some heavy async calculation of that response

All nesting can be expressed this way. (Convince me otherwise)

This property of monads is why Clojure has a threading macro, Haskell has pointfree, and most ML derivatives have a concept of piping.

E.g. you can define function gamma that is expressed as alpha | beta (Aka beta(alpha(x))) that just takes a url and spits out a single promise of a processed http response, but still isn’t nesting!

[Dave Jacoby]

I recently took a function with many nested ifs to modify two variables and rewrote it to return immediately instead. It was much more readable but didn't work when put into testing, but the point is that nesting makes things more complicated and harder to read.

That can be necessary; required behaviors can be complex. But it's kinder to your brain and those of the next dev to flatten.

[Sebastian Vargr]

I depends on verbosity in my case.

In nested code i find my self often looking for where indented sections end.

If i don't have to do look for where things end, then i'm find.

Consequently, this is usually around 2-3 indentations.

After that i often start to run our of useful vertical screen-space and the moment a indented section cross into where i cannot see it, then it becomes a problem to track again.

[Nick Holmes]

Nesting control structures quickly creates very many possible code paths, which makes the code harder to read, harder to work on, and, perhaps most importantly, harder to test. For this reason, it should be avoided/minimized.

[Sébastien Vercammen]

All scoping is nesting.

[Nick Holmes]

I would suggest that scoping is data structure nesting, not control structure nesting, and therein lies a vitally important difference.

[Sébastien Vercammen]

Everything's a data structure.

[Paweł Kowalski]

Nesting when you write is very useful, given its obvious in your editor.

Nesting in output, probably not useful at all.

Nesting when writing logic, i would say, i try to do as little of that as possible, because parsing that in my brain is a chore.

[Jesse M. Holmes]

This is the answer I came for. :)

[Michiel Hendriks]

Without proper deep levels of nesting how can I post my hadoken gif?

[Ben Halpern]

😄

[Jason C. McDonald]

From a Python perspective, we are informed by the Zen of Python

Flat is better than nested.

Python provides many patterns that allow one to avoid nesting in most cases. Of course, it's not altogether unavoidable, but you should try to avoid going any deeper than 2-3 levels, functions included.