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

[Daniel Bates]

I just had to change a void function to a non-void function in <
https://bugs.webkit.org/show_bug.cgi?id=195281>. I was very happy that all
of the existing code was written by people that did not return void because
I didn't have to change any call sites returning void into two lines. This
saved me time, kept the patch minimal, avoided dirtying line history, and
avoiding me having to do a double-take whenever I see a return void.

Is there a path forward for this issue? Should I put together an online
survey for people to vote? I don't want this issue to fall into a void ;)

Dan

On Feb 21, 2019, at 10:32 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

On Thu, Feb 21, 2019 at 9:31 AM 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.
>

Perhaps this is the key distinction we want to make. Maybe if the *intent*
is to ignore the function's return value regardless of what it may return
in the future, then we should have a separate "return". If the *intent* is
to return whatever that other function returns, then we should return void.
But having to think about the intent of code isn't a great thing for coding
style guideline.

- 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.
>

This is an orthogonal point but I do prefer switch'es that return directly
over one that break's then having a separate return after the switch
statement especially if the switch statement is long.

I've gotta say I'm fascinated to learn that many people are bothered by
returning void. I guess I was never bothered by it because I see a return
statement as a thing that returns the control back to the caller, not a
thing that returns a value.

- R. Niwa

_______________________________________________
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/20190305/f392a03b/attachment.html>