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)
/**
 * Verifies and returns the last installation task that was completed.
 *
 * @return
 * @return null|string
 *   The last completed task, if there is one. An exception is thrown if Drupal
 *   is already installed.
 */
function install_verify_completed_task() {
  try {
    $task = \Drupal::state()->get('install_task');
  }
  // Do not trigger an error if the database query fails, since the database
  // might not be set up yet.
  catch (\Exception $e) {
  }
  if (isset($task)) {
    if ($task == 'done') {
      throw new AlreadyInstalledException(\Drupal::service('string_translation'));
    }
    return $task;
  }
}
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

bbrala created an issue. See original summary.

bbrala’s picture

  1. When closing an issue as an result of our meeting, what should we close it as? We are no maintainers on coding standard project, therefor, things like credits and such are impossible to give. I decided on RTBC 2 weeks ago, but i'd like to get agreement on this.

quietone credited longwave.

quietone’s picture

Issue summary: View changes

@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!

quietone’s picture

Status: Active » Needs review
smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Reviewed 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.

quietone’s picture

Status: Reviewed & tested by the community » Fixed

These 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.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

quietone’s picture

Project: Drupal core » Coding Standards
Version: 10.0.x-dev »
Component: meetings » Meeting

This should be in the Coding Standards project.