4 ms·
I appreciate this. I think one of the more valuable advice I was given re:conditionals is to make sure the positive path is the non-branching path. Branch you
by devchix 5y ago
I appreciate this. I think one of the more valuable advice I was given re:conditionals is to make sure the positive path is the non-branching path. Branch your exception, let your expected path fall through.
if ( unexpected = true )
branch;
do_expected_stuff
Caveat: ways to do things age. Maybe this is no longer true or even slightly advantageous, but so far it has served me.
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.
- Izkata 5y agoThis particular use of an if statement is subset of what's called a "guard clause", and I'm also a major fan of them. Other guards include an early return for edge cases or that would make the more general path more complicated, rather than just exceptions. https://wiki.c2.com/?GuardClause/ https://wiki.c2.com/?GuardClause/
- Schwolop 5y agoI learnt this one early on and definitely still encourage it (but aware of your caveat too). But I describe it differently when I'm coaching, and I think I've used the phrase "try to get your conditionals out of the way early". 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?
- gabssnake 5y agoaren't these ill defined guards?