Manual:Coding conventions/PHP#cite_note-3

...currently leads to a task with access restrictions. If it doesn't contain any sensitive information, is it possible to make it public -- and if it does, is it possible to convey the relevant information within it in another way? Friendly ping to Lucas Werkmeister (WMDE), as you added the section in question :) Best, ‍—‍a smart kitten_[meow] 14:58, 14 January 2025 (UTC)

@A smart kitten This is now done. Taavi (talk!) 04:45, 15 January 2025 (UTC)

Does the convention about not using empty() still apply?

In a recent patch, we were using empty() for checking if an array was, well, empty, but switched it to count( $value ) > 0 due to this convention ("The empty() function should only be used when you want to suppress errors"). However, after doing so, SonarQube complained about not using empty() in this case (the error was Use empty() to check whether the array is empty or not.). So I suppose this convention may no longer apply, or the Sonar config needs to be updated? HArroyo-WMF (talk) 10:06, 18 June 2025 (UTC)

In general, you should trust human-written documentation over SonarQube, which isn't configured with our policies but instead some upstream point-of-view of what they think code should look like, sadly. I believe it still holds. Jdforrester (WMF) (talk) 14:57, 18 June 2025 (UTC)

That makes sense, thank you HArroyo-WMF (talk) 16:20, 19 June 2025 (UTC)

Actually, there’s a much simpler solution, which is hopefully not flagged by SonarQube either: $value !== []. Since PHP arrays are compared by value, an array is unequal to [] if and only if it’s non-empty. (The coding convention suggests !!$value – which is equivalent to (bool)$value –, but doesn’t discourage $value !== [] either, and I think it’s more expressive if you know you’ll only handle arrays, never nulls, boolean values etc.) —Tacsipacsi (talk) 16:28, 23 June 2025 (UTC)

Readonly properties

PHP properties correspond to the following grammar in PHP 8.1 (a bit simplified):

property-declaration:
 property-modifiers-var type-without-staticopt property ";"

property-modifiers-var:
 property-modifiers
 "var"

property-modifiers:
 property-modifier
 property-modifiers property-modifier

property-modifier:
 "public"
 "protected"
 "private"
 "static"
 "readonly"

[...]

The order of the individual property-modifiers is insignificant. The first three cannot appear together, but they can be combined with either of the latter two, so all these declarations are legal:

<?php
class Foo {
	// PHP 7.4+
	public static int $bar;
	static public int $baz;

	// PHP 8.1+
	public readonly int $a;
	readonly public int $b;
	public function __construct(
		private readonly int $x,
		readonly private int $y,
	) {}
}

PER-CS 2.0 only allows $bar, $a, $x, similarly its predecessor PSR-12 only allows $bar (PSR-12 was written before PHP 8.1, so it doesn’t discuss readonly). Our coding conventions allow everything, since they don’t discuss this matter at all. Shouldn’t we also prescribe the order for consistency? —Tacsipacsi (talk) 17:27, 23 June 2025 (UTC)