Ask HN: Is arrow code sometimes unavoidable?

[Jigsy]

So a while back I changed my awful coding habits to "if (!true) { return } ..." after reading a post about "flattening arrow code."

But it got me wondering about conditions with multiple instances such as: "if (true) { if (!true) { return } ... }"

Is arrow code sometimes unavoidable? Or should I be setting flags for everything?

[uberman]

I always try to use guard code to quick return, but I also find no rule is absolute. If a guard makes your code easier to write and understand then use it. If you feel like you are doing gyrations to place a guard then it might not make sense.

[JohnFen]

I have a general opinion about this sort of thing: no programming pattern is always bad or always good. Even gotos are not always harmful.

The important thing is clarity of code. If arrow code makes that part of the code easier to understand and less likely to lead a future dev (who may be you!) to make a mistake, then it's a good thing.

If setting flags makes that code easier to understand and less likely to lead a future dev to make a mistake, then that's a good thing.

It all depends on the project, and has to be balanced with a consistent approach also being a good thing. If flags are used everywhere else, then use them even if arrow code would be more clear for a given section, and vice versa. This is the purpose for "house rules" about coding style, and such house rules are usually the best way to go.

My TL;DR is: anytime someone says that "X is always good" or "X is always bad", that person is wrong. X may usually be good or bad, but there are always exceptions.

[Jigsy → JohnFen]

Yeah, goto gets a bad wrap imo.

I mean, sure, nobody should be using it for loops, but if you're jumping right to the end of a function (or a while loop) and doing cleanup operations, is that such a bad thing?