Ask HN: Is arrow code sometimes unavoidable?

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.

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.