Coding Standards Meeting Wednesday 2026-03-04 0700 UTC [#3576923]

Hello all, it’s time for the fortnightly coding standards meeting.

This meeting:
➤ Is for anyone interested in the Drupal coding standards.
➤ Is held on the #coding standards channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Usually happens fortnightly. Alternating between Tuesday 2100 UTC and Wednesday 0900 UTC.
➤ The meeting open for 24 hours to allow for all time zones.
➤ Discussion is done in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously.
➤ Has a public agenda anyone by adding a comment to the meeting issue.
➤ A transcript will be made using drupal-meeting-parser and posted to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.
➤ The transcript will include comments made during the 24 hours of the meeting. However, comments made after the 24 hours may not be in transcript.

Current ping list: @catch, @longwave, @quietone
@dww, @borisson_ @longwave @Björn Brala, @Aaron McHale, @Alex Skrypnyk, @Kingdutch, @Tyler Staples (nexusnovaz)

0️⃣ Who is here today? Comment in the thread to introduce yourself. We’ll keep the meeting open for 24 hours to allow for all time zones.

borisson_	:wave:
catch	:clap:
Tyler Staples (nexusnovaz)	Hey - Almost missed this one (or maybe i did) - How do i get added to the ping list?
borisson_	Edit[#3576923]
borisson_	That will be copied to next time, we only just started, so there's still time to comment on the threads
quietone	@Tyler Staples (nexusnovaz), I'll add you to my ping list.
Tyler Staples (nexusnovaz)	Thank you, i did edit the issue above. Its too early for me so i thought the 9AM i saw was yesterday!Going to take a read through and get myself caught up and see what im able to contribute to discussions!
longwave	:wave:
dww	Derek in the Hawaiian Kingdom

1️⃣ What topics do you want to discuss? Post in this thread and we’ll open threads for them as appropriate.

borisson_	https://www.drupal.org/project/coding_standards/issues/2816445 I wonder how we can get consensus here?
borisson_	https://www.drupal.org/project/coding_standards/issues/2108785This is not yet rtbc, but I think it's good to go, there's one remark on the merge request, but I think it's otherwise good to go
longwave	would like to discuss[#3441699]

2️⃣ Action items

2️⃣.1️⃣ Approve minutes for previous meeting(s)

quietone

Thanks to @borisson_'s reviews these are all Fixed.

2️⃣.2️⃣ Issues to go to core committer meeting

quietone

https://www.drupal.org/project/coding_standards/issues/3360160

2️⃣.3️⃣ TBD

3️⃣ Fixed since last meeting

quietone	Traits should always have the suffix "Trait"
quietone	Update references to PSR-4
quietone	Update references to Simpletest
quietone	Move content to accessibility page
quietone	Allow omitting @var, @param and @return tags or their descriptions if the variable name and type is enough
quietone	Use of "e.g." and "i.e."

4️⃣ RTBC issues

4️⃣.1️⃣Backslash on global class names outside of a namespace

borisson_	This is making the rules a bit stricter, we need to figure out if this would fit the new small changes rule? I think this does because there are not a lot of non-namespaced files left anymore.We need to figure out a rule that we can apply for this, but I think this can go to the core committer committee
catch	It would affect using global classes in namespaced code too if I'm reading correctly, we should probably update the title. The actual change looks good.
catch	I don't think many people do use Exception so for me that'd still fall under a small change.
borisson_	I think, if I read the previous rules correctly, this was already supposed to be the case?Classes and interfaces without a backslash \ inside their fully-qualified name (for example, the built-in PHP Exception class) must be fully qualified when used in a namespaced file. For example: new \Exception();. Do not use global classes.
quietone	new small changes rule?
borisson_	Well, if it needs the blogpost?
catch	Ohh I was reading the 'before' text :confused:
quietone	LOL.
catch	This will only be relevant for .install files
catch	Well, and lots of custom/contrib code that hasn't switched to OOP hooks yet, but otherwise pretty much only install/update hooks at this point, so definitely not worth a blog post I think.
quietone	Anyone know if this can be enforced?
catch	I found allowFullyQualifiedGlobalClasses but that's our status quo, not the same as requiring. It probably means it's possible to enforce though since the detection would be the same.

4️⃣.2️⃣ Stop using FQCN in PHPDoc annotations

borisson_	This needs a change record still
borisson_	But I think it can go to the Core Committer Committee
Jonathan1055	Rebased the MR, and now with the newer Gitlab Templates release you can test the documentation changes

5️⃣ Other topics

5️⃣.1️⃣ Proposal to not make a blog for 'small' changes.#3523279: Add conditions to deciding if a blog post is needed

5️⃣.2️⃣ The process is that the committee reviews issues once they are RTBC

quietone	I was strolling through the queue and there are quite a few issues where there is agreement and that is all.
quietone	The work to implement the change and have it ready for the committee is missing.
quietone	The issues need an MR, a change record, and investigation for how to enforce it.
quietone	Any ideas on how to get those steps done?
borisson_	There's a task for creating a change record, but I guess we could add those 3 points to that same task?
quietone	So, I have misunderstood. The issues are going to NR when they could go to RTBC and then we carefully go through the remaining steps.
borisson_	But yes, I think we can already look at all the needs review issues here as well, because I think some can definitly go to rtbc, or they just need a comment with the next steps so we can bring them back to life?
quietone	Yes, I agree. I'll move triage here up my list.

5️⃣.3️⃣ Forbid using more than one space around operators from @borisson_

borisson_	I really think this would benefit us, but looking at the issue we are currently at +7, -5, so I wonder how we are going to build consensus on this issue?
quietone	Does a PSR have anything related?
quietone	When space is permitted around an operator, multiple spaces MAY be used for readability purposes. From PSR-12
borisson_	Yeah, it's allowed there
quietone	We can ask on the issue if anyone would block a decision that went against their preference.
quietone	There is also an option to set a time limit on the discussion. Say about 1 more month. If still no consensus then add a date to the title and postpone it until that date. I would go with 2 years for this one.
Tyler Staples (nexusnovaz)	I'll add my comment to the issue, but i am +1 for this. I don't mind seeing multiple spaces, but more often than not, its also fine for just a single space to surround an operator.Multiple spaces can improve readability but that is on fairly rare occasions imo
longwave	i am really on the fence about this one and see the argument from both sides; personally neither style bothers me that much to have an opinion

5️⃣.4️⃣ Remove the requirement for doxygen for test methods from @borisson_

longwave

added a suggestion to the MR for this one

5️⃣.5️⃣ Replace @inheritdoc annotations with #[\Override]

longwave	@inheritdoc feels dated to me and the language level feature provides some benefit in that tools can detect when an overridden method has no parent implementation any more
borisson_	I wonder what the impact of this on the api docs is? I think that currently has special treatment for inheritdoc and we'd need to make that work with Override as well
longwave	yeah we would need api.d.o support for sure but it is effectively the same, just better
borisson_	That shouldn't block us though
longwave	fwiw Symfony does not document their overrides at all and PHPStorm etc still work perfectly with it
borisson_	that was going to be my next question :smile:
quietone	Any downsides?
borisson_	Since its a language construct, does it impact performance?
borisson_	If it doesn't, I don't really see any downsides, other than someone having to dive in to api.d.o :smile:
quietone	There is a CS issue,#3335320: Stop using {@inheritdoc} in DocBlocks, use [#\Override] instead
quietone	Comment 19 may answer the question about performance
longwave	doing this might mean we could also introduce another rule: allow @return types to be overridden in docblocks on #[Override] methods - which would help phpstan in some cases where we can't actually add the return type yet
longwave	the rules explicitly forbid this in @inheritdoc docblocks
longwave	this is useful when the base class declares e.g. EntityInterface as the return type, and you know in a subclass that you can narrow it further
borisson_	Sure, that makes sense, that's a good reason to do this. It's currently a core issue, do we need to make it a coding standards issue?
longwave	there is already the CS issue that quietone linked above
borisson_	I updated the tile for that issue to make it a bit clearer