[Webkit-unassigned] [Bug 225817] New: Proposed change to WebKit Code Style Guidelines for if-return-else-return

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=225817

            Bug ID: 225817
           Summary: Proposed change to WebKit Code Style Guidelines for
                    if-return-else-return
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sam at webkit.org

I'd like to propose a change to the WebKit Code Style Guidelines (https://webkit.org/code-style-guidelines/) specifically around this rule: https://webkit.org/code-style-guidelines/#linebreaking-else-if. 

The current rules state that "An else if statement should be written as an if statement when the prior if concludes with a return statement." Additionally, this is generally construed to apply to else statements after a return being elided entirely as well. e.g.

    if (condition)
        return foo;
    else
        return bar;

should be written as:

    if (condition)
        return foo;
    return bar;


I think we should remove this rule and leave it up to the writer to choose how to style this, allowing both else-if after a return and else after a return. My arguments for allowing this are:

- It is often easier to follow logic if you can read out the "if, else-if, else-if, else", rather than having to notice that there is a return in the statement and adding the else in your head.
- For single line conditions like the above example, the lining up of the return statements is pleasing.
- For constexpr if, the elses are required, so we have to break the rule for them anyway.

I'm eager to paint this bike shed, so what do you think?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210514/19df154d/attachment.htm>