Hacker News Reader

Comment by janlaureys | Hacker News Reader

That Fibonacci based indentation might not be a bad idea after all. Especially when doing callback-style javascript.

Or as a cautionary measure against heavily nested code.

, but you repeat yourselves.

I think something simpler like (n)(n+1)/2 is better. This means that the difference between the n-th and (n+1)-th indentation level is n spaces (barring of by one errors I made).

We still get a curving indentation, and we are still warned against nesting, but the indentation doesn't explode exponentially.

there's also the "inverse fibonacci mode", where the indentations become smaller and smaller at each level

it feels like when your handwriting becomes more compressed as you are about to reach the right end of the paper

I'd prefer something like 3^n. Would really make you try to avoid needless nesting.

Make it 1.3063778838630806904686144926...^(3^n), where 1.306... is Mill's constant. Then all your indents will be to prime columns.

Why should I avoid needless nesting ? Is there any other reason besides the holy 80 character limit !? Nesting can for example be used to limit variable scope and make use of closures, or to avoid creating more code paths, or just make the code more readable. You can however often break some code down to named functions and it will be easier to read, with the added benefit of less nesting. But I don't see how avoiding nesting is a good rule by it's own.

You've given some good examples of nesting which don't introduce branches, but most nesting does and therefore, nesting is an approximation for the cyclomatic complexity of a piece of code. Reducing this complexity helps with testability and (moreso) with the ability of humans to understand the code https://en.wikipedia.org/wiki/Cyclomatic_complexity

Agree with you that reducing nesting is not in and of itself beneficial.

Cyclomatic complexity seems like a great example of Goodhart's Law [1]. I absolutely agree that on the whole, code with fewer paths tends to be easier to read. However, taking deeply nested code and arbitrarily pulling chunks of it out into functions which only have a single caller and don't really abstract anything that's ever going to be terribly meaningful on its own seldom makes it better in my experience -- and can force a lot of skipping around if you're actually trying to understand what the system as a whole is trying to do.

[1] https://en.wikipedia.org/wiki/Goodhart%27s_law

If you punish nesting a smart developer might use imaginable horror (with the same or worse complexity) to keep the code flattened. Nesting makes the complexity apparent.

> Why should I avoid needless nesting ?

Because it is, by definition, needless. If there is a good reason for doing so, it is no longer needless.

Highly nested code is hard to understand.

I think it would help with clarity - too much nesting in a function can mean it's doing too much and might need splitting into several functions

One place where nesting makes things difficult is in error handling.

If at each potential error point you best one level, you quickly find yourself deeply nested.

I find the pattern of exiting early and having the “happy path” running to the end of the scope to make it much easier to comprehend a function (I’m sure there’s a term for this coding style but I can’t find the name of it at the moment).

I also find myself doing a similar thing in loops - 'continue'ing early instead of wrapping everything in conditionals.

Reply on news.ycombinator.com