30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
I generally follow a similar pattern, which is also known as 'early return' and nicely explained here by Szymon: szymonkrajewski.pl/why-should-you-...
What matters to me is that there is a common pattern to functions across a codebase, so the reader (hello you in 15 months time) can see the 'happy path' easily, and can see the priority of unhappy conditions, which communicates what matters more too.
Use of assertions or guard conditions also results in a similar pattern for good reason :)
I've been using this method for years now and can definitely say it makes code far more legible and concise. If/else has it's place at times, but I really think (and hope) that early returns should be taught as a standard practice.
Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
I once argued AGAINST early return, but then I tried it and I can't imagine why I didn't use it before.
Early on in my career (a long time ago in a galaxy far far away and all that) I had been taught a rule that a function should only ever have one return in order to make it clear what was being returned, and I clung to that rule for too long.
It's one of the best changes I've made to my code style in years. I love it.
I am an OpenEdge (aka Progress) developer that loves clean code and good looking applications that are easy to use. My main pet project is the Progress DataDigger
I generally follow a similar pattern, which is also known as 'early return' and nicely explained here by Szymon: szymonkrajewski.pl/why-should-you-...
What matters to me is that there is a common pattern to functions across a codebase, so the reader (hello you in 15 months time) can see the 'happy path' easily, and can see the priority of unhappy conditions, which communicates what matters more too.
Use of assertions or guard conditions also results in a similar pattern for good reason :)
I've been using this method for years now and can definitely say it makes code far more legible and concise. If/else has it's place at times, but I really think (and hope) that early returns should be taught as a standard practice.
I once argued AGAINST early return, but then I tried it and I can't imagine why I didn't use it before.
Early on in my career (a long time ago in a galaxy far far away and all that) I had been taught a rule that a function should only ever have one return in order to make it clear what was being returned, and I clung to that rule for too long.
It's one of the best changes I've made to my code style in years. I love it.
I was taught exactly the same thing, but when you adhere to that you end up with massive blocks. Early return is king!