Convert all "long" array syntax to "short" syntax, and make it the official standard?

[swampopus]

The Question:

In core, should we stop using array(1, 2, 3) in favor of [1, 2, 3] ? And, should we adopt short syntax as the standard way of writing arrays in Backdrop?

Example:

$x = [
  'key' => 'val',
];
function ($x = []) {}
return l('foo', 'bar', ['attributes' => ['class' => 'fun']]);

Previous work on short syntax

@quicksketch has already created a working proof of concept for a rapid conversion to short syntax: backdrop/backdrop#4936
In case the blog post he mentioned disappears one day, here is what it said to do:

1. Require code sniffer in your project (you are using composer, right?)
   `composer require --dev squizlabs/php_codesniffer`
2. Run CBF using the DisallowLongArraySyntax sniff
   `vendor/bin/phpcbf . --standard=Generic --sniffs=Generic.Arrays.DisallowLongArraySyntax`
That will apply to everything in the current directory, so simply change the . to whichever specific files/folders you want to affect.

-- from https://philipjohn.blog/2023/02/10/convert-php-arrays-to-short-array-syntax-in-seconds/

[yorkshire-pudding]

I'm not personally in favour of this change; I find the standard array syntax easier to spot generally.

If the standard were to change to allow this, then it should not be a one or the other. The Backdrop standard, should allow both, even if for core a decision is made to move to the short syntax (side note: who is volunteering to do that code review?). I would also strongly advocate against adding a test into the Backdrop PHPCS standard that showed the standard array syntax as a warning or error as this would negatively impact on contrib modules where the maintainer wanted to stay with the standard array syntax.

[avpaderno]

In Backdrop core, I would use long array syntax as long as PHP supports it. It is just a syntax change without other pro.
Contributed projects should be able to decide which syntax to use. As long as they are consistent in the used syntax (short or long array syntax), that should not be a problem.

[swampopus]

I also prefer array() but to play devil's advocate, lots of other PHP-based open source projects state that short [] syntax is required.

Some examples I could find easily that explicitly require short syntax:

• Moodle (part of their php codesniffer rule)
• Simple Machines Forum
• Drupal
• Laminas

And to play devil's advocate's advocate 😈, Wordpress explicitly requires long syntax:

• Wordpress

[quicksketch]

My opinion is that it's worth the effort to change to the short syntax for core.

• The short array syntax is better because it's shorter.
• It aligns with other languages and the rest of PHP itself. It's bizarre that all other array operations like assignment and concatenation are brackets but instantiation is like a function. This inconsistency is why the short array syntax was created in the first place, because the original/long-array PHP syntax just doesn't make sense from a consistency standpoint.
• Replacing every long usage with short usage has been shown to be trivial and can be done in seconds with perfect accuracy.
• I don't like that it will break every single open PR against core, but that would be a short-term problem worth the change.
• Comparatively, updating documentation would probably be the biggest burden compared to updating core syntax.

I also think we should only use one syntax or the other. If we don't go with short syntax, core should stick to long syntax universally.

[indigoxela]

I've no strong opinion, with a slight tendency to long array syntax.

I can see how short array syntax is beneficial for people developing for both, Backdrop and Drupal. AFAIK that's true for all our core committers. Many contributors, however, are on Backdrop exclusively (or Backdrop and Wordpress?).

Besides dev consistency for Drupalists, there's actually no real benefit in switching to short. Long syntax won't get deprecated, and it's definitely easier to spot. And given, all existing PRs would break... maybe it's not worth it.
But I'm fine with either - long and short syntax.

[swampopus]

I tend to agree with @indigoxela, for all of the reasons she mentioned.

I also don't feel super-strongly one way or the other, but I will admit that when I saw how many other OSS projects enforce short syntax, I am slightly leaning towards short syntax now, for one main reason: it makes Backdrop feel more like "modern" software.

I mean the average non-dev isn't even going to notice, and neither would non-core contributors, but nevertheless, I do see it as a valid reason:

New contributors will have likely only been using short syntax in their other projects.

People under the age of 30 🐣🍼 or so will likely only have been writing PHP with short syntax, and it aligns with how Javascript inits arrays, and how JSON and YAML (sorta) handle array values. So that means the young-ish programmer would be used to writing JS and JSON arrays with a similar short syntax, and if they learned with PHP in the last 14 years, they've likely been using short syntax as well.

Personally, I still like array() for readability, but, as I said in Zulip, this isn't a hill worth dying on. I'm fine with either syntax.

[avpaderno]

To avoid requiring changes in the existing PRs, postponing the conversion to Backdrop 2.x would be a possible solution. (I suppose the existing PRs will be merged before Backdrop 2.x.)

[swampopus]

I think it could be faster: I'd suggest for the existing PRs to comment on them and ask the maintainers to switch to short syntax, and ask that all new PRs use short syntax. Then, for version 1.36 (or whatever) of core, we could switch to all-short syntax, and it would be much less disruptive because hypothetically all the PRs at that time will already be in short syntax.

[avpaderno]

The "disruptive" part would be changing all the existing PRs.
It would be less disruptive if PRs created after a certain date would be required to use short array syntax, but that would mean knowing that after that date Backdrop core code is already changed to use short array syntax. It would not work for those PRs created before that date which are still not merged into Backdrop core after that date, though.

[bugfolder]

While I appreciate all the points people have made on both sides of this issue, I personally incline toward short syntax for the reasons @quicksketch outlined.

Since I have about 15 PRs against core that have been aging for various periods of time (oldest for 5 years: #5274), I would find having to update the PRs a bit annoying, but worth the effort to me—especially if the tool that "flawlessly" updates code could be easily run. PRs written by people who are no longer particularly active, though, would be more problematic.