I've used an outbound-only landline, for going on two years; the previous two decades I always carried a work cell phone. It's incredible that even years later, if I happen to hear my former ringtone (used by other people), or hear that familiar `buzzing` sound: I still get anxious feeling like I must respond to these ficticious nobodies...
The portability of the cell phone is IMHO what made it so addictive / disruptive. Back when most computers didn't fit into our pockets society had clearly delineated spaces between online/offline — now everything is connect so nothing is...
It's not remotely the same thing. Social media apps are highly engineered addiction serotonin-drips.
You had wrongthought because back then there was at least a chance that the material was objective. Today you have Fox News et.al. and scores of highly propagandized feeds spewing nothing but agenda-pushing propaganda.
The toyota code was a case of truly abysmal software development methodology. The resultant code they released was so bad that neither NASA, nor Barr, nor Koopman could successfully decipher. (Although Barr posited that the issue was VERY LIKELY in one of a few places with complex multithreaded interactions).
Which therein lies the clue. They wrote software that was simply unmaintainable. Autogenerated code isnt any better.
It helps prevent bugs with state. The apple login bypass bug comes to mind.
Basically, you have code in an "if" statement, and if you return early in that if statement, you might have code that you needed to run, but didnt.
Forcing devs to only "return once" encourages the dev to think through any stateful code that may be left in an intermediate state.
In practice, at my shop, we permit early returns for trivial things at the top of a function, otherwise only one return at the bottom. That seems to be the best of both worlds for this particular rule.
> In practice, at my shop, we permit early returns for trivial things
Are you also writing C or similar? If so, then this rule is relevant.
In modern languages, there are language constructs to aid the cleanup on exit, such as using(resource) {} or try {} finally {} It really does depend on if these conveniences are available or not.
For the rest of us, the opposite of "no early return" is to choose early return only sometime - in cases where results in better code, e.g. shorter, less indented and unlikely to cause issues due to failure to cleanup on exit. And avoid it where it might be problematic. In other words, to taste.
> Kent Beck, Martin Fowler, and co-authors have argued in their refactoring books that nested conditionals may be harder to understand than a certain type of flatter structure using multiple exits predicated by guard clauses. Their 2009 book flatly states that "one exit point is really not a useful rule. Clarity is the key principle: If the method is clearer with one exit point, use one exit point; otherwise don’t".
reply