Bug 194848 – [Code Style] Functions returning void

• Component: WebKit Website
• Status: RESOLVED WONTFIX

[Daniel Bates]

WebKit Dev thread: <https://lists.webkit.org/pipermail/webkit-dev/2019-February/030439.html>

It has been a long standing, unwritten policy, that return statements should be written expression-less and on their own line in functions that return void. And a return statement on its own line in a function returning void should be omitted when its effect is equivalent to falling off the end of the function.

From the WebKit dev thread (linked above), I strongly support this policy and so does Tim Horton [1]. Ryosuke Niwa seems supportive, acknowledging that WebKit "tend[s] to have a separate return." and replying to Tim Horton's "+1" with support for codifying this unwritten policy [2]. Although he did not reply to the thread, Darin Adler has acknowledged "our style has been to not return void" in his remarks in bug 194485, comment 5. Alex Christensen seems to be the lone respondent that is strongly opposed to the unwritten policy [3]. All other respondents to the thread to date have expressed no strong opinion.

[1] <https://lists.webkit.org/pipermail/webkit-dev/2019-February/030440.html>
[2] <https://lists.webkit.org/pipermail/webkit-dev/2019-February/030441.html>
[3] <https://lists.webkit.org/pipermail/webkit-dev/2019-February/030444.html>

[Daniel Bates]

Created attachment 362479 [details]
Patch

[Daniel Bates]

When I have a moment I will look to teach the style checker to enforce this rule. I do not feel we need to wait for style checker support to move forward and amend the code style guidelines in light of the support for this policy.

[Ryosuke Niwa]

Comment on attachment 362479 [details]
Patch

As far as I can tell, there isn't a strong consensus either way.
As such, I don't think we should make this coding style guide change right now.
r-.

[Daniel Bates]

(In reply to Ryosuke Niwa from comment #3)
> Comment on attachment 362479 [details]
> Patch
> 
> As far as I can tell, there isn't a strong consensus either way.

Please read the bug description.

> As such, I don't think we should make this coding style guide change right

You're remarks are confusing. You wrote, emphasis mine:


[[[
I much prefer doing this in my own code **but stay away from it in WebKit
because we tend to have a separate return.**
]]

AND

[[
On Thu, Feb 7, 2019 at 12:53 PM Tim Horton <timothy_horton at apple.com> wrote:

> +1 to a style guide update
>

Yeah, we **might as well as codify it in the style guideline for clarity.**

]]

Yeah, we might as well as codify it in the style guideline for clarity.

> now.
> r-.

I'm so confused what you're position is. What is is?

[Daniel Bates]

Ryosuke, your argument does not follow from the discussion as far as I can tell. I'm inclined to put this up for review again because 1) your argument does not follow for the discussion 2) your comments seem to contract your own words in <https://lists.webkit.org/pipermail/webkit-dev/2019-February/030441.html> and 3) you have not provided any constructive criticism of the content of the patch or provided guidance on a path forward. Instead you put up a wall and tell me "I don't think we should make this coding style guide change *right now*."

[Ryosuke Niwa]

(In reply to Daniel Bates from comment #5)
> Ryosuke, your argument does not follow from the discussion as far as I can tell.

It totally does. Just look at the latest reply on webkit-dev. I think you misinterpreted people's responses.