Code style for php [] array arguments - need advice

143 views
Skip to first unread message

Hrvoje A.

unread,
Jan 18, 2018, 10:56:53 AM1/18/18
to PHP Framework Interoperability Group
// is this allowed or is it a personal preference?


SomeClass::someMethod([
  'arg1' => 111,
], [
  'arg2' => SomeClass::someMethod([
     'arg5' => 999
  ]),
], [

  'arg3' => [
    'arg4' => 'zzz'
  ]
]
);

//
// vs all array notations must be in new line
//

SomeClass::someMethod(
  [
    'arg1' => 111,
  ],
  [
    'arg2' => SomeClass::someMethod(
      [
        'arg5' => 999
      ]
    ),
  ],
  [
    'arg3' => [
      'arg4' => 'zzz'
    ],
  ]
);



Joe T.

unread,
Jan 19, 2018, 9:08:00 AM1/19/18
to PHP Framework Interoperability Group
My understanding of PSR-2 (and 12) is only the second one is permitted.

PSR-12 4.5
Argument lists MAY be split across multiple lines, where each subsequent line is indented once. When doing so, the first item in the list MUST be on the next line, and there MUST be only one argument per line.

With that said, the shorter arrays can be condensed to single line if they fit. So you could have:
SomeClass::someMethod(
   
// also, 4-space indents ;)
   
['arg1' => 111],
   
// Okay, but in my opinion starts to risk readability.
   
['arg2' => SomeClass::someMethod(['arg5' => 999])]
   
['arg3' => ['arg4' => 'zzz']]
);

Hrvoje A.

unread,
Jan 20, 2018, 5:17:17 AM1/20/18
to PHP Framework Interoperability Group
Thank you for the reference to PSR-12 - I was looking for that.

What about 4.7 Method and Function Calls
A single argument being split across multiple lines (as might be the case with an anonymous function or array) does not constitute splitting the argument list itself.
somefunction($foo, $bar, [
  // ...
], $baz);

I would say that the new array notation does bring some benefit to code readability. 
Opening and closing angle brackets ([]) for arrays could be treated like function/method curly brackets ({}).

Joe T.

unread,
Jan 20, 2018, 12:34:26 PM1/20/18
to PHP Framework Interoperability Group
The short-style syntax does make arrays much more readable, as it no longer makes them look like function calls.

However, the rule you're referencing is for when you are keeping arguments on the *same* line. It permits for splitting an array in that signature to multiple lines, and continuing the signature after the end of the multi-line array.

i see now your first example was following the guideline of the format from your second message. Your right, technically that does comply with the standard. When you start the signature on the same line as the opening "(", all successive arguments after should continue on the line where the previous argument ends. But hopefully you can see how muddled that pattern is for readability. It's hard to tell where the arrays begin or end, particularly in context of being function arguments. So many commas and brackets...

Honestly, i dislike the standard's allowance of the style in your second message. It seems very awkward and visually clunky to me. But i don't have a vote in accepting the standard, and came to the group a bit late to make a case for changing it. For me (and the guide my team uses), any time any argument is split to multiple lines, the whole signature should follow the multi-line signature rule.

Ultimately, i think the goal is readable & maintainable code, so when two versions are technically legal, let that objective be the deciding factor.

Hope that helps.
-jlt

Miguel Rosales

unread,
Oct 26, 2018, 12:42:30 PM10/26/18
to PHP Framework Interoperability Group
Sorry I'm new to the group so I'm not 100% aware of the process, but the site says PSR-12 is under draft, so I guess things can still be discussed...

I was going to open a new topic about this but found this one, and just wanted to say I agree with the previous message - I don't like this part of the recommendation:

A single argument being split across multiple lines (as might be the case with an anonymous function or array) does not constitute splitting the argument list itself.

somefunction($foo, $bar, [
   
// ...
], $baz);


$app
->get('/hello/{name}', function ($name) use ($app) {
   
return 'Hello ' . $app->escape($name);
});

I know many developers are used this in some scenarios, but particularly when there are many arguments it gets lets readable.
Also I assume that implementation of auto-formatting allowing this would be quite trickier (in fact for example PhpStorm doesn't support this atm).

So, is this something that has been decided already or is it open to changes?

Joe T.

unread,
Oct 26, 2018, 10:05:45 PM10/26/18
to PHP Framework Interoperability Group
For what it's worth...

The requirement for my team is that any time a function call spans multiple lines, all arguments must be split to individual lines, and any additional formatting for the arguments goes according to their own rules.

someFunction(
    $foo
,
    $bar
,
   
['short', 'array', 'arg'],
    $baz
);
//or

someFunction(
    $foo
,
    $bar
,
   
[
       
'longer' => 'array',
        'with' => 'keys',
        'or',
        'other',
        'mixed up stuff',

    ],

    $baz
);

i find the PSR incredibly frustrating sometimes. It seems it's not written for readability and consistency (especially to assist young devs to acclimate quickly), it's written so legacy code authors won't cry. That's a cynical statement, i suppose, but some of the rules seem to have no rationale behind them.
-jlt

Jan Schneider

unread,
Oct 29, 2018, 4:37:54 AM10/29/18
to php...@googlegroups.com

+1

Zitat von Joe T. <thoo...@gmail.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 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/2083e29f-f66e-4769-a6fb-f6b9dc710586%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.




Jan Schneider
The Horde Project
https://www.horde.org/
Reply all
Reply to author
Forward
0 new messages