[webkit-dev] Code Style: Opinion on returning void

Nico Weber thakis at chromium.org
Wed Mar 20 05:46:36 PDT 2019

On Thu, Feb 21, 2019 at 12:31 PM Darin Adler <darin at 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 at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20190320/fdc0c00a/attachment.html>

More information about the webkit-dev mailing list