[DISCUSS] Disallowing trailing comma in function and method definitions

[tag Knife]

Since the RFC to allow this behavour in PHP 8 has been accepted, I wish to start talks on if we should amend PSR-12 to allow or disallow trailing commas in function and method names.

There is general confusion within the community why this RFC has been firstly proposed and mostly accepted. With others welcoming the change as they apparently do this error all the time.

Personally I have never had a problem with accedently trailing a comma in parameter lists and against this RFC, I think it promotes learned bad habits instead of allowing people to learn from mistakes.

I am for disallowing trailing commas in parameter lists in either PSR-12 or any future code style.

Discuss.

RFC: https://wiki.php.net/rfc/trailing_comma_in_parameter_list

[Alexandru Pătrănescu]

Hi,

For me, trailing commas feature is surely useful and the main advantage for me is to have a smaller diff on code reviews.

For TS this is the tslint rule I use:

"trailing-comma": [true, {"multiline": "always", "singleline": "never"}],

basically stating that if the list is multi line, it is enforced while on single line is denied.

AFAIK, PSR-12 currently does not have any rule for trailing comma in any place that it could be used and, IMO, it should be kept like this, to allow both your and my styles.

Regards,

Alex

 

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/345a4919-6a2e-47c3-a932-c2f12d312f07%40googlegroups.com.

[Larry Garfield]

Some context: That RFC was inspired by the parallel RFC for constructor promotion:

https://wiki.php.net/rfc/constructor_promotion

With that, it becomes more likely that constructors will be written "vertically," especially when combined with attributes, which are also about to pass:

https://wiki.php.net/rfc/attributes_v2

In that case, having a comma on the last line has all the same advantages as for vertical array definition. When it's inline (the normal horizontal style we're all used to) then the extra comma really doesn't have a benefit.

Disallowing the use of a new PHP feature entirely seems... pointless and counter productive, especially given the use cases it was intended for are about to become a lot more common.

From a process standpoint, PSR-12 is now immutable; it can have errata added, but that's it. We've discussed before that fixed-PSRs are probably a not-good model for a coding standard (esp since PHP 8 is going to have a number of new features that PSR-12 obviously doesn't cover), and this is another example of that.

In the short-term, the best that could be done here is an errata saying "vertical things that allow a trailing comma should allow a trailing comma just like arrays do," but that would by definition be non-binding.

I think at this point the answer is "do nothing until we figure out a new process for living standards rather than just fixed-point standards."

--Larry Garfield

[Matteo Beccati]

Hi,

so, we just voted the feature in (58 vs 1), but you'd like to disallow
it in PSR-12. I don't think that is a good move, as much as you hate the
feature yourself.

Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

[Chris Tankersley]

On Wed, Apr 29, 2020 at 11:38 AM 'Matteo Beccati' via PHP Framework Interoperability Group <php...@googlegroups.com> wrote:

Hi,

so, we just voted the feature in (58 vs 1), but you'd like to disallow
it in PSR-12. I don't think that is a good move, as much as you hate the
feature yourself.

The issue isn't so much whether we hate or love the feature, it's that PSR-12 was locked in before that was an available feature. At the time, because of how PSRs are immutable essentially, the choice was either continue to hold off doing PSR-12 until PHP X.Y comes out with new features (and write a spec for a feature against no usage to back up the spec), or update the spec with what was currently available. There will always be new features and syntax being added, and with immutable PSRs they will always be somewhat behind.

The better fix would be to allow living PSRs, but we currently don't have those.

 

On 29/04/2020 11:20, tag Knife wrote:
> Since the RFC to allow this behavour in PHP 8 has been accepted, I wish
> to start talks on if we should amend PSR-12 to allow or disallow
> trailing commas in function and method names.
>
> There is general confusion within the community why this RFC has been
> firstly proposed and mostly accepted. With others welcoming the change
> as they apparently do this error all the time.
>
> Personally I have never had a problem with accedently trailing a comma
> in parameter lists and against this RFC, I think it promotes learned bad
> habits instead of allowing people to learn from mistakes.
> I am for disallowing trailing commas in parameter lists in either PSR-12
> or any future code style.
>
> Discuss.
>
> RFC: https://wiki.php.net/rfc/trailing_comma_in_parameter_list


Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f956015c-0552-3960-77ba-6434e0c1ea89%40beccati.com.

--

Chris Tankersley
http://ctankersley.com

[Niels Braczek]

Am 29.04.20 um 18:31 schrieb Chris Tankersley:

> The better fix would be to allow living PSRs, but we currently don't have
> those.

Wouldn't that be easily achievable by applying semantic versioning to
the PSRs?

Regards,
Niels