So a while back I changed my awful coding habits to "if (!true) { return } ..." after reading a post about "flattening arrow code."<p>But it got me wondering about conditions with multiple instances such as:
"if (true) {
if (!true) { return }
...
}"<p>Is arrow code sometimes unavoidable? Or should I be setting flags for everything?
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.<p>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.<p>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.<p>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.<p>My TL;DR is: anytime someone says that "X is always good" or "X is always bad", that person is wrong. X may <i>usually</i> be good or bad, but there are always exceptions.