Hello all, it’s time for the fortnightly coding standards meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for anyone interested in the Drupal coding standards.
➤ Usually happens fortnightly on Tuesday 2100 UTC. The meeting open for 24 hours to allow for all timezones.
➤ Is done on the #coding standards channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens 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 can add to. See the parent issue for an idea of the typical agenda.
➤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.
Standing items
- Who is here?
- What should we talk about today? Suggest topics here and I will add threads. I will also check for comments on the issue for today's meeting.
- Action Items
- Approve previous minutes
- Wrap up
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 timezones.
| longwave | hello! |
| Björn Brala (bbrala) | Good morning, was already sleeping :) |
| kingdutch | :point_up_2: |
0️⃣.5️⃣If you could live anywhere on our planet, where would it be?
| quietone | Italy is attractive |
| Björn Brala (bbrala) | Hmm, where I live right now :sweat_smile: |
1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.
| quietone | Update on issue targets for this beta |
| quietone | Adding Drupal practice standards |
| quietone | Drupal Coding standards in PHPStorm |
| Björn Brala (bbrala) | #3312049: [Followup] Fix Drupal.Commenting.FunctionComment.MissingReturnType returns for NULL follow up for the committed beta target issue. Do we want that:) |
| kingdutch | Is there any work ongoing on allowing more complex type annotations? E.g. array or Box ? |
| borisson_ | I don't think so, but I don't think our standards currently disallow it |
| kingdutch | There's a specific PHPCS rule that will barf at syntaxes like those because it disallows < and > (instead it suggests array|int|string or Box|EntityInterface which is completely different) |
| Björn Brala (bbrala) | Hmm, i vagualy remember this. Not sure if there was an issue. My colleage was looking into this i think...? (cc @casey) |
| kingdutch | Ah #3253472: Support advanced PHPStan data types (general, arrays) |
| kingdutch | If I type coder into my URL bar it's actually the search that surfaces this :sweat_smile: |
| Björn Brala (bbrala) | wow |
2️⃣ Action items
2️⃣.1️⃣ Wins - what wins have you had since the last meeting? Share your successes!
2️⃣.2️⃣ Approve last fortnight's minutes
| quietone | #3306969: Coding Standards Meeting 2022-09-13 2100 UTC |
| Björn Brala (bbrala) | +1 on rtbc, but did I post those? :sweat_smile: |
4️⃣Adding Drupal practice standards, #3310127: [META] Fix DrupalPractice best practice in Core (edited)
| quietone | @Jonathan1055 made an issue summarizing what Drupal practice standard core follows and does not follow |
| quietone | It is great to have this in one place! |
| quietone | My biggest concern is the same as point 4 in the Issue Summary, That is to be sure that core has a policy to follow a particular Drupal practice standard first. |
| Björn Brala (bbrala) | Hmm, will need to look from a pc, missing the issue link here so need to search |
| quietone | Oops. I added the link to the start of this thread. |
| Björn Brala (bbrala) | Hmm, this could become hard. I do not know the contents of the sniffs, but i think that 'best practices' are less mandatory than real codestyle. In my mind it would make sense to have the rules that might live in practice that seem like they should be adhered to should be a coding standard. Why have 2 sets xD If i go by that thought process, i think it is kinda weird we have 4 of them in core. Shouldn't those just move? |
| Jonathan1055 | Thanks for looking at this. To summarize, there are 40 sniffs in DrupalPractice, and 4 of them are included in core phpcs.xml.dist and thus checked for. There are a further 20 which core code passes but which are not being checked. So we have 24 sniffs passing and 16 not passing. With more than half passing that implies to me that it is/was the intention for Core to pass it's own recommendations on best practice. I don't think we want to start moving DrupalPractice sniffs into Drupal coding standards, as that sounds like a lot of work for very little benefit. |
5️⃣ Drupal Coding standards in PHPStorm
| quietone | This is wonderful to see progress here. |
| quietone | Is there anything we can do to help this effort? |
| longwave | https://youtrack.jetbrains.com/issue/WI-46482 would be nice to see fixed (or we adopt @inheritDoc ) |
| quietone | :eyes: |
| quietone | There is an issue for this, #3060580: Allow inheritdoc and inheritDoc? |
| longwave | agree that it is ugly to allow both and that changing our standard seems like a waste of time, but i totally get why PHPStorm don't want to change this either |
| kingdutch | Do we know what other frameworks like Symfony do? Or are we the only framework enforcing inheritance and the rest just skip comments altogether? |
| longwave | symfony does use {@inheritdoc} like us in places, but is much more inconsistent (often docblocks are missing entirely) |
6️⃣ return types NULL follow up on committed return type issue
| Björn Brala (bbrala) | #3312049: [Followup] Fix Drupal.Commenting.FunctionComment.MissingReturnType returns for NULL |
| Björn Brala (bbrala) | This made sense to me, empty return is meh imo. What do you think? |
| borisson_ | I disagree, empty returns also convey some value, they mean: I just want execution to stop and I don't care about what is returned. (edited) |
| Björn Brala (bbrala) | Sure, but shouldn't that be void then? |
| Björn Brala (bbrala) |
|
| kingdutch | I think we should just follow the wider PHP community and be explicit in our final NULL returns.
I don't entirely understand the debate. PHPStan already warns about this exact scenario. https://phpstan.org/r/848a5b50-4525-415e-a7aa-cadfea465095 Even if I follow the initial hint of "remove NULL because it never returns NULL" then I get "Function test() should return string but return statement is missing." which also indicates that I forgot to think about something. https://phpstan.org/r/9a0087a9-05ae-47d9-bc25-da93dc1f7cae Adding a return NULL at the end indicates that I've thought about my return types and the code is complete. If this should never return NULL then apparently $b not being always TRUE is an error and I should end with throwing a helpful exception instead. |
Comments
Comment #2
bbralaComment #7
quietone commented@bbrala, sorry, I forgot to check this agenda for the discussion topic and missed your comment. I have added it to the next minutes. Let's hope it is remembered next time!
Comment #8
quietone commentedComment #9
smustgrave commentedReviewed this as part of the need review queue initiative.
Taking look at 9/28 in the slack channel appears all conversation was captured and everyone that contributed was awarded credit.
Not part of that but feel comfortable saying this is good.
Comment #10
quietone commentedThese minutes can be marked fixed once it have been reviewed and credit is applied. The core committers don't need to see these issues.
I am crediting smustgrave for the review and marking fixed.
Comment #12
quietone commentedThis should be in the Coding Standards project.