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.

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

2️⃣ Action items

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

borisson_ This is rtbc, looked good to me

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

3️⃣ Fixed since last meeting

3️⃣.1️⃣. Welcome to @borisson_ as a member of the Coding Standards Committee

quietone Great to have you on the team[#3580157]
Kingdutch :blob_party:

4️⃣ RTBC issues

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

quietone This is still waiting for a change record.
quietone Who can do that?
Kingdutch Created an initial version for people to shoot at in https://www.drupal.org/node/3587469Not sure if that's entirely what we're looking for but it's easier than starting from 0 :smile:
borisson_ Change record looks good to me, I will comment on the issue

4️⃣.2️⃣ Classes and interfaces without a backslash \ inside their fully-qualified name must be fully qualified

quietone I did bring this up in the core committer meeting channel and there were no objections.
quietone There is a change record and MR, so this looks fine for committing, publishing the change record and setting to Fixed.
quietone Anyone see anything else to do here?
Kingdutch Added my +1 to it
borisson_ No looks like we followed all the steps we should have. So I agree we can commit this

5️⃣ Other issues

5️⃣.1️⃣ Forbid using more than one space around operators

quietone The last few comments support having a standard so we avoid a mix of styles.
quietone And for that the single space is the preferred option. So, I guess we should pursue that.
quietone We never state in the standard but when a case is better formatted another way we can add ignore lines. Perhaps that is the practical way to move this along.
quietone This needs an MR.

5️⃣.2️⃣ Remove the requirement for doxygen for test methods

quietone Looks like this needs review of the MR I created earlier this month and a review of the change record.
borisson_ I think the MR is already reviewed, longwave had one remark and we've fixed that. I already created the cr, so I can't really review it :confused:

5️⃣.3️⃣ Stop using {@inheritdoc} in DocBlocks, use [#\Override] instead

quietone This is being discussed and doesn't have 3 supporters.
quietone If anyone wants this to be a standard, comment on the issue and add yourself as a supporter.
quietone It will also need an MR and change record.
quietone This seems more about keeping up with the ecosystem. That is, a simple task.
Kingdutch Is that annotation the right one when it’s a method implementing an interface ? In that case there’d be a difference between inheritdoc and override. So I feel it's not a 1:1 replacement  (edited)
quietone
Instead, for showing that a method overrides something from a parent class, use [#\Override] instead.

From the proposed resolution on the issue.
borisson_
Is that annotation the right one when it’s a method implementing an interface ? In that case there’d be a difference between inheritdoc and override. So I feel it's not a 1:1 replacement

Good point, but most ide's already don't need this when implementing a method from an interface, it will already get the documentation  from there. We'd need to get the same thing to work in the api project (which will be difficult). I think we only need that attribute when overriding a parent method.
borisson_ I didn't think about then when I added support to the issue
Kingdutch Not at a laptop yet, but I would propose retitling the issue to clarify "for class, omit for interface".The issue title currently reads as if the attribute is the direct replacement which made the text ambiguous. It's not really a direct replacement, but a situational parallel

Participants:

quietone, Kingdutch, borisson_

Comments

quietone created an issue. See original summary.

quietone’s picture

quietone commented
Title: Coding Standards Meeting Tuesday 2026-04-26 2100 UTC » Coding Standards Meeting Tuesday 2026-04-28 2100 UTC
quietone’s picture

quietone commented
Issue summary: View changes
Status: Active » Needs review