if ( unexpected = true )
branch;
do_expected_stuff
I also prefer 20 lines of simple pedestrian code to 2 lines of clever code. I remind myself that I write for the maintainers, who do not have the benefit of my resident knowledge when they encounter the code.
My rationale is that having done this, I'm left with a smaller combinatoric mental space to work within. Like "if the program counter has reached this point then I know for a fact that X, Y, and Z don't apply - the function would have exited early if they did". And that then means the remaining set of things I have to keep in my working memory is reduced, which makes life easier.
Is that similar to how you see this advice?
Prioritize your backlog to reduce/eliminate 2 AM pages. That's the metric you care about; not tickets, not test coverage, not logging/metrics. All those others are gameable metrics. The only thing that matters other than reducing pages are features, and you'll find that by prioritizing the former, you end up delivering faster on the latter over the long haul.
... has an "else" whether it's written or not. Choose carefully whether to skip writing it, but always know it's there
I try to impress that not as much upon developers, but religiously upon folks writing requirements. Many pieces of code work just fine without the else, but the amount of bugs and rewrites due to someone either not considering "but of course it always succeeds!" or because there was an implied else scenario in their head that they just didn't bother to write down are almost innumerable.
To buck the trend, I'm going to add a few "hard skills" lessons I've learned from managers.
From the best: "Every if statement is death" was an adage of one. He encouraged me to think deeper about whether conditionals were really needed, and at what place they were needed. That mindset helped me write clearer and more easily testable code.
From the worst: In code, "brilliant" solutions are like poems: they're beautiful, they're terse, and they pack a lot of meaning into each line. To mid-level engineers, they have an intoxicating appeal, because they seem like a good way to flaunt their talents. But more often than not, what is really needed is the code version of ordinary prose: straightforward, with a preference for clarity over succinctness, easy for others to understand, easy to edit, and with fewer surprises and deviations from convention than a poem. Your goal should not be to impress your code reviewer with your cleverness but to impress the person who needs to maintain your code three years from now.