nested ifs work here too. i personally don't think cognitive overload is an issue because you are not composing all the conditions at once. in fact, each block should only care about one condition. but you make a good point.
tbh, i have seen nested ifs used in video game programming a lot. and i came to the conclusion that it has to do with the else clause that the return early method doesn't provide. the else clause is always doing something because games are never supposed to fail...
The cognitive overload is not just in having to mentally parse a single complex conditional check on a single if statement. It's more an aggregate effect of having to mentally compose all of the conditions of the outer if/else branches that a line of code is contained within in order to reason about the code within that branch.
I'd also add that it's a good idea to break out complex condition checks to their own independent if statements on separate lines. I'd even go further and decompose the condition expression into individual boolean variables so that if you build in debug mode you have all the evaluated values held in variables for inspection. In release mode the variables should be compiled away.
There are some practical and aesthetic benefits that come from reducing nesting and breaking apart complex if conditions:
* less horizontal scrolling in your editor
* no need to parse complex boolean expressions all stuffed into very few `if` statements
* easier ability to step through code within a debugger and follow the execution logic more exactly
* more distinct line numbers for crash dumps / stack traces to refer to in order to exactly identify which condition or evaluation is causing a failure
That last point is very beneficial when you hand your code off to someone else and they send you back a stack trace to investigate. Your code probably crashed at a complicated line of code full of boolean-combined expressions and any one of them could be at fault. All you know for sure is that something went wrong at that line number. No other hints given as to what went wrong or what the value of all the relevant variables on that line are.
I also wanted to comment on needing it because games aren’t supposed to fail. The way you actually do that is not to try to recover from errors but to surface them quickly and fix them at the point of failure. Ideally before shipping. Recovery is usually very difficult because games are a collection of very dependent state and if you don’t recover correctly letting the game continue after an error is very likely to result in all sorts of other bizarre issues happening. This can also be very subtle where the accumulation of errors leads to a sudden obvious issue and finding the root cause is very difficult. Whereas failing early and loudly makes things much easier.
They work here too, but they're unnecessary since explicit short circuits are more readable and result in cleaner code. Apart from the obvious visual improvement, it encourages you to write functions that do one thing. Excessive use of "else" and branching can be a code smell. Over time, I've started using "else" less and less. I don't remember the last time I even used an "else".
> If cond return err means everything after is an implicit else block
Right, but inverting to get to return early format means that the “else block” that needs to do substantive work becomes the if block, and it needs to be doing something substantive not just “return err”.
Which may be a valid criticism in some cases, but doesn't seem to be in this particular code base, where most of the ifs don't have an else and those that do it's log-error-and-return.
tbh, i have seen nested ifs used in video game programming a lot. and i came to the conclusion that it has to do with the else clause that the return early method doesn't provide. the else clause is always doing something because games are never supposed to fail...