[PSR-12] Function declarations with multiline arguments AND return type declaration

[Nic]

I cannot find an answer to this question: what should a function/method declaration look like if it has arguments that are split over multiple lines, AND a return type declaration?

PSR-12, in it's current state, states the following:

When the argument list is split across multiple lines, the closing parenthesis and opening brace MUST be placed together on their own line with one space between them.

However, this does not leave any room for a return type.

I would assume that a method with multiline arguments and a return type would look like this:

function (
    string $foo,
    string $bar,
    int $baz
): string {
    echo 'foo';
}

Is this a correct assumption? And perhaps PSR-12 should be updated to clarify this?

[Richard Fussenegger]

I would really love a more generic approach to a coding standard than the existing PSR-2 and the upcoming PSR-12. All these conditionals are in the end just material for formatting tools and not for humans.

// 1TBS

element {} // If empty

element {
    // If not empty
}

// Ergo
element {

}
element {

}

Always do that no matter where or what and it really lives up to what it should: lower the cognitive load while writing code.

[Woody Gilk]

I would say:

element {

}

(Just eliminate the blank line so there is no question about whitespace.)

--
Woody Gilk
http://about.me/shadowhand

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/66f8973f-9dae-4ef8-bc18-fc4c1e94bd9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Fussenegger]

I did not want to open that can of worms but it should be answered in a good convention. However, the posted rule (regardless of whitespace) is completely future proof forever and it is dead simple to follow and remember. Heck, it even makes files smaller (scrolling and downloading [even with Gzip]).

[Korvin Szanto]

Hi,

 Yep, that's how the current PSR-12 spec would have you do it today. I'm currently (very very slowly) putting together a poll that we're going to use for contentious issues, I'll make sure we have this case listed.

@Richard, I'd be glad to talk with you on IRC and explore that more if you'd like. My schedule is pretty full but I check up on IRC daily.

Thanks,

Korvin

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ee5c58a7-e556-4cea-b761-fc3683541e14%40googlegroups.com.

[Alexander Makarov]

https://github.com/cs-extended/fig-standards/issues/33

[Vinor cola]

Hello,

I'd like to argue against this syntax: 

function (
    string $foo,
    string $bar,
    int $baz
): string {
    echo 'foo';
}

It make code not easily readable since you cannot efficiently separate arguments from function body: there is no clear separate between them, and the whole function looks like a signle block. Instead, I'd propose:

function (
    string $foo,
    string $bar,
    int $baz
): string
{
    echo 'foo';
}

or

[Korvin Szanto]

Hi Vinor,

I'm of the mind that having the closing parenthesis not indented provides enough of a visual break. 

That said the current PSR-12 spec allows for new lines after your opening bracket in your function declaration so your last example is completely valid.

Best wishes,

Korvin

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/98bc7ef8-33e2-4c0b-b68f-b5b7b39284be%40googlegroups.com.

[Vinor cola]

Please check this: https://youtu.be/ZsHMHukIlJY?t=1319 (watch few minutes, especially where the guy replace the code with X)

Understand that visualy, a parenthesis is not enough to quickly make a block distinction. This is a matter of readability: you cannot at a glance get where parameters ends and where code starts. You said PS-12 allow new lines after opening bracket. I think in this particular context, it should make the new line mandatory.

[Korvin Szanto]

Thank you for your efforts here Vinor, it's very much appreciated! I do disagree with the idea that we should require a new line, instead we should continue to leave it up to the implementor of PSR-12 whether they'd like a newline or not. I've added this discussion to the meta document for anyone that comes across this issue and is wondering what the best way to handle this is: https://github.com/php-fig/fig-standards/pull/939

Best wishes,

Korvin