Plugin-php: Force array/list shorthand notation

Created on 30 Jan 2019  路  22Comments  路  Source: prettier/plugin-php

Force the use of shorthand array's, (available since php 5.4)

Reasoning:

The old syntax looks like a method call, not like an array.
The new syntax is shorter and improves readability as it looks like an array.

Other issues regarding array's use the shorthand notation in their example code, indicating a preference towards shorthand.

Input:

$my_array = array(1, 2, 3);

Desired output:

$my_array = [1, 2, 3];
discussion enhancement

Most helpful comment

During implementation a related question about list formatting came up: Since PHP 7.1, lists also have a short form, i.e.

list($a, $b) = $arr;
# becomes
[$a, $b] = $arr;

Currently, we're printing the form just the way we find it - but since we introduced phpVersion it would be possible to always print the short form when phpVersion >= 7.1, and otherwise always the long form.

What do you think? Feel free to post a :+1: reaction for automatic conversion to short forms (just like we decided to do for array) or :-1: to leave things the way the are now.

All 22 comments

hm, we need --engine option for this improvement, because some people can use prettier for php5.3/php5.2 and lower. Not sure it is part of prettier, maybe better use linter for this.

/cc @czosel

Is there any reason not to use the shorthand on newer PHP versions, though? (I, for one, would really like this transformation.)

@hawkrives no, we officially support php5.0, php5.1 and etc so we can breake their code, it can be solved only added engine field, but it is discussed

These kind of transformations are not Prettier's job, but instead done by a linter. PHP-CS-Fixer seems to support this use-case as well (array_syntax). If PHP-CS-Fixer also supports automatically fixing rule violations, a setup like eslint-prettier for JS would be possible for us as well.

These kind of transformations are not Prettier's job, but instead done by a linter. PHP-CS-Fixer seems to support this use-case as well (array_syntax). If PHP-CS-Fixer also supports automatically fixing rule violations, a setup like eslint-prettier for JS would be possible for us as well.

For anyone who's interested in integrating prettier into the workflow of php-cs-fixer as a fixer, I've wrote a customised fixer to execute prettier before all other fixers.
https://gist.github.com/Billz95/9d5fad3af728b88540fa831b73261733

@Billz95 i think we can add this to docs/recipes

@Billz95 i think we can add this to docs/recipes

Hmmm sorry would you mind elaborating a bit on docs/recipes? Couldn't find much info about it, thx

@Billz95 we can create recipes directory and put your example, also add link on this in README, it is allow faster integrate prettier for other developers

Other idea - use composer.json to determinate php version, it is increase 0CJS configuration. Example:

{
  "require": {
    "php": "^7.1",
  }
}

If composer.json doesn't found we don't change anything and print all as is.

@hawkrives no, we officially support php5.0, php5.1 and etc so we can breake their code, it can be solved only added engine field, but it is discussed

Why would you be supporting wildly out-of-date, hardly-used, deprecated versions of PHP?
I would suggest PHP 5.4 as the earliest, as it still has a significant user-base (albeit still deprecated).

I second this suggestion. PSR-2 isn't explicit on array syntax, but their examples are shorthand: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md#43-methods

@xbuzz because we should not break code, it is prettier

@evilebottnawi You may have accidentally tagged the wrong person there.

I understand the concern however, this is catering for ~20% of PHP 5 users (https://w3techs.com/technologies/details/pl-php/5/all), whom are using legacy systems, and likely have no intention or desire to use a tool like Prettier.

The tradeoff is that this propagates a syntax that is not recommended, barely used by the consensus (PSR-2), and unusual in the grand scheme of things. All for the sake of the minority.

That being said, a reasonable compromise here would be to simply allow the config to determine long vs short array syntax.

Forcing long-form array syntax would be an unfortunate deal-breaker here, and I am sure I am not alone in that.

@xdega I don鈥檛 think there is any talk of forcing long-form array syntax鈥攋ust leaving array syntax unchanged.

I鈥檓 in favor of forcing short form array syntax If the composer.json file requires a version of PHP new enough to allow it. This seems like something that should be in prettier鈥檚 purview to me鈥攁rray syntax is esssentially a formatting choice, since the two forms are functionally identical. I see it in the same class of changes as changing double quoted to single quotes in js, as prettier already does.

@xdega 20% seems like an aggressively high estimate. That could be outdated.

According to packagist, it looks to me like it's about 2%, and according to WordPress, it's around 7%.

I think it's fine to support short array syntax, and I think it's absurd that prettier wants to support PHP 5.0. Yikes. PHP 5.0 reached end of life 13 years ago.

/cc @czosel looks we need option, --engine (it is allow to use change syntax for array and heredoc/nowdoc, for php7.3 we don't need add extra newline after <<<), also we search composer.json and try to get version to avoid extra arguments and configurations

@karptonite Good point about the analogy to single/double quotes! From a user perspective I liked the idea of rewriting arrays from the beginning, but I wanted to make sure that we鈥檙e not slowly adopting too much linting functionality. Anyway, I鈥檓 all in for rewriting arrays now!

@evilebottnawi Sounds good!

While we wait for prettier to implement rewriting the array notation,
I'll share my workaround with phpcbf (PHP Code Beautifier and Fixer):

phpcbf --standard=Generic --sniffs=Generic.Arrays.DisallowLongArraySyntax file.php

We just posted a little RFC-style issue that proposes a way to move forward with this over at #1280. Your feedback would be appreciated!

During implementation a related question about list formatting came up: Since PHP 7.1, lists also have a short form, i.e.

list($a, $b) = $arr;
# becomes
[$a, $b] = $arr;

Currently, we're printing the form just the way we find it - but since we introduced phpVersion it would be possible to always print the short form when phpVersion >= 7.1, and otherwise always the long form.

What do you think? Feel free to post a :+1: reaction for automatic conversion to short forms (just like we decided to do for array) or :-1: to leave things the way the are now.

Array shorthand syntax has landed in v0.14.0, but let's keep this issue open until shorthand list syntax has landed as well (#1351).

@czosel Thanks for your work here. Much appreciated.

Was this page helpful?
0 / 5 - 0 ratings