Bug 194848

Summary: [Code Style] Functions returning void
Product: WebKit Reporter: Daniel Bates <dbates>
Component: WebKit WebsiteAssignee: Daniel Bates <dbates>
Status: RESOLVED WONTFIX    
Severity: Normal CC: darin, jond, rniwa, thorton
Priority: P2    
Version: WebKit Local Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch rniwa: review-

Description Daniel Bates 2019-02-19 20:45:58 PST
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>
Comment 1 Daniel Bates 2019-02-19 20:50:13 PST
Created attachment 362479 [details]
Patch
Comment 2 Daniel Bates 2019-02-19 20:51:36 PST
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.
Comment 3 Ryosuke Niwa 2019-02-19 21:43:44 PST
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-.
Comment 4 Daniel Bates 2019-02-19 22:23:33 PST
(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?
Comment 5 Daniel Bates 2019-02-19 22:45:02 PST
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*."
Comment 6 Ryosuke Niwa 2019-02-20 09:44:20 PST
(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.