On Thu, Feb 21, 2019 at 12:31 PM Darin Adler <da...@apple.com> wrote:
> I tried not to weigh in on this, but my view on the materials we should > use to build the bike shed must be shared! > > Generally it seems neat to be able to make the code slightly more tight > and terse by merging the function call and the return into a single > statement. > > Other than not being accustomed to it, I have noticed three small things I > don’t like about using “return” with a call to a void-returning function. > > - You can’t use this idiom when you want to ignore the result of a > function, only if the function actually returns void. Often functions are > designed with ignorable and often ignored return values. For example, it’s > common to call something that might fail and have a good reason to ignore > whether it failed or not. The idiom we are discussing requires treating > those functions differently from ones that return void. If you refactor so > that a function now returns an ignorable return value you need to visit all > the call sites using return and change them into the two line form. > That works, you just have to spell it `return (void)non_void_fun();` :D > > - It works for return, but not for break. I’ve seen at least one case > where someone filled a switch statement with return statements instead of > break statements so they could use this more-terse form. Now if we want to > add one line of code after that switch, we need to convert all those cases > into multi-line statements with break. > > - Unless it’s mandatory, it’s a case where two programmers can make > different style choices. If both forms are acceptable, then it introduces a > little bit of disorder into our code. > > One thing I like about it is that since “pass along the return value from > this inner function to this outer function” can be written this way, the > code can then survive refactorings where both the inner and outer functions > might gain or lose the return value. > > — Darin > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
