Coding Standards Meeting Wednesday 2025-06-25 0900 UTC [#3527210]

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, @Urvashi, @Kingdutch

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.

catch	:wave:
borisson_	:wave:
nicxvan	Hi

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

quietone	https://www.drupal.org/project/coding_standards/issues/3521628
borisson_	Approved

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

#3521443: Traits should always have the suffix "Trait"
#3376518: Allow omitting @var, @param and @return tags or their descriptions if the variable name and type is enough

2️⃣.3️⃣ TBD

3️⃣ RTBC issues

3️⃣.1️⃣ Formatting fixes, whitespace, links, rename files

quietone	This appears to be complete.
quietone	If nothing was missed it can be 'fixed'.
Jonathan1055	yes lets say its fixed 🙂

3️⃣.2️⃣ Traits should always have the suffix "Trait"

borisson_	I am personally not a big fan, but there seems to be community agreement on this one?
quietone	And I am fine with this.
quietone	I do wonder why this wasn't added earlier. I wonder if there was some earlier discussion.
borisson_	I think this might be from before traits were a thing? :smile:
quietone	Ah, that could be.
borisson_	I checked and traits are php 5.4 (march 2012), our coding standards are older than that
quietone	It looks like a sniff change is in order. I get the following when changing an interface name 14 \| WARNING \| Interface names should always have the suffix "Interface"
quietone	But I don't get a similar error when changing a trait name.

4️⃣ Conversion to GitLab pages

4️⃣.1️⃣ Updates for using GitLab pages

quietone	This is just for changes to the project page and the template to use GitLab pages.
quietone	So, needs a review to make sure that the changes make sense.
quietone	Should be a simple review.

4️⃣.2️⃣ Redirects for Coding standard pages to GitLab pages

quietone	In this issue drumm has asked a question,#3530663: Redirects for Coding standard pages to GitLab pages#comment-16156831
quietone	This would delete the d.o pages. Are we ready for that?
borisson_	Once the final content check is done, I think we are
quietone	The pages are ready for final checks.

5️⃣ Test related

5️⃣.1️⃣ Define a standard for naming data providers in PHPUnit-based tests

quietone	joachim asks a good question. What happens with a dataprovider is used by more than one test method. How does that change the method names?
quietone	It is convenient when the provider and test method have similar names.
quietone	I did find some data providers in core that do not use the word 'provider' in the title. That required some extra reading to figure out what the method was for. It would have been saved some time if the method name made that clear.
borisson_	I don't think the names have to match the test names. I have gotten into the habit of doing something like provideMenuLinks - a name that is based on what is being returned. If there are multiple needs it could be provideInvalidMenuLinks/provideValidMenuLinks .I agree with the having provide or provider in the method names, and I personally prefer the earlier, because that way we kind of force people to come up with a name that means something?
borisson_	I have commented on the issue now as well
quietone	I usually use 'provider'. But I was just thinking that if the provider was documented then the name doesn't really matter. The doc block would tell the reader what the method is for.

6️⃣ Allow omitting @var, @param and @return tags or their descriptions if the variable name and type is enough (edited)

quietone	donquizote has suggested new text that needs community review.
quietone	This is about the use of 'fully-qualified'. (edited)
quietone	It is best to read the comments.Do people agree or disagree with the proposal?
borisson_	I am not sure if we need to be this super technically correct in the coding standards, to this document is for reading by humans, not machines. The fully-qualified type makes sense to me and I understand it to also include types that can not be fully qualified because they are not a class.To me the latest comment looks good and I think it can go in.
acbramley	Agree with @borisson_
nicxvan	Getting that nitty gritty will be a blocker for most people I think
nicxvan	Who here knows the difference between the four options without looking them up (edited)
nicxvan	Is the proposed up to date
nicxvan	Basically i agree with @borisson_ as well
quietone	To summarize, the choice is betweenEach parameter of a function must be documented with a @param tag (see exceptions below).andEach parameter of a function must be documented with a @param tag with a fully-qualified type. (see exceptions below).The first is the current text on the coding standards pages. The second is the proposal of this issue, that was previously agreed to. The difference between the two is the addition of the phrase, with a fully-qualified type.
acbramley	how about we leave it as is since there's some conflicts around that new wording, I agree it's weird since string is allowed and may not be considered a "fully-qualified type" to some. We can do a follow up to discuss refining it later
quietone	That make sense and allows for incremental improvements. Do others agree?
borisson_	I agree yeah, we can improve now and make it even better later.