Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.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.
| bbrala | Hi! Checking in from the beach :sweat_smile: |
| quietone | Lucky you! Storming and cold here. |
| bbrala | Oh wow :sweat_smile: |
| (anonymous) | Comment Redacted |
| borisson_ | :wave: Not from the beach, but there's a public holiday tomorrow, so looking forward to spending some time in the sun as well 🙂 (edited) |
| catch | :wave: |
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)
| quietone | https://www.drupal.org/project/coding_standards/issues/3513862 |
2️⃣.2️⃣ Issues to go to core committer meeting
2️⃣.3️⃣ TBD
3️⃣ RTBC issues
3️⃣.1️⃣ Require using a colon after case instruction in switch statements
| quietone | This is at final review. So, if there are no objections at this meeting then documentation updates will be next. |
| bbrala | All for |
3️⃣.2️⃣ Adopt phpstan phpdoc types as canonical reference of allowed types
| quietone | This is at final review. So, if there are no objections at this meeting then documentation updates will be next. |
| bbrala | Yes, this is good (edited) |
3️⃣.3️⃣ Allow omitting @var, @param and @return tags or their descriptions if the variable name and type is enough
| quietone | This is at the first review by the committee. |
| quietone | For myself, I find the proposed text long and harder to figure out what needs to be done. |
| quietone | None of the parameters need a descriptionHow will this be decided? Who decides? |
| quietone | To say it is the developer is limited. The developer is likely to have intimate knowledge of the code and may not think that a description is needed. Whereas, the description is for someone new to this code, someone that needs some extra information to fully grasp the situation. |
| quietone | Also, this should explicitly state which sniffs are affected, which ones will no longer be used etc. (edited) |
| borisson_ | I agree that this is very long text, but it is quite clear to me. |
| borisson_ | It would be good to know what sniffs are affected |
| bbrala | It is readable. Personally I'd be less explicit in the description to make it more readable.Like description could be something gLike; when the type and variable are self explanatory the description can be omitted.But I understand why it ended up with such a lots of requirements."Add param, return and descriptions only when they convey more i formation that the type and variable name". Kinda ambiguous |
| acbramley | I think the new text is much more readable than what's currently there. I think the proposed text would actually replace all 3 of the first bullet points in that section and not have the confusing "see exceptions below" next to each of them (where are those exceptions??) |
4️⃣ Moving coding standards docs from d.o to GitLab pages
| quietone | If they are in a repository then we don't need to monitor changes to the pages by the community to confirm they are correct. |
| quietone | An MR can be supplied on the issue to review text changes with GitLab |
| quietone | For example, see https://project.pages.drupalcode.org/governance/ |
| quietone | Anything think this is useful or not worth the effor? |
| borisson_ | I think this is very useful and a very good idea |
| bbrala | That would be smart thing to do. Let's make an issue and get it rolling.Covert current docsGenerate pages from docsUpdate links to pagesUpdate d.o. doc pages to redirect (or link) to new location.Update process to include docs mr in some step. |
| quietone | OK! Here is the issue,#3521924: Convert Coding Standards to GitLab pages |
| borisson_ | I will try giving this a go after work today |
Comments
Comment #2
quietone commentedComment #6
quietone commentedComment #7
borisson_All the comments are in there, looks good.
Comment #8
quietone commented