Allow omitting @var for strictly typed class properties

+1, yes!

Good first step but needs several followups

1. Allow omitting doxygen altogether. It's just not necessary to add any doxygen to protected LockbackendInterface $lockBackend. Optionally yes but most of the time the type tells the story
2. Extend to @param and @return and entire method doxygen. Once again, these might be completely unnecessary. protected function getLockbackend(): LockbackendInterface , gee, I have no idea what this method could possibly be about, let me try to guess.

Add the existing documentation to the Issue Summary.

It will help if someone would complete the proposed text section of the Issue Summary.

Took a shot at a proposed text

Filed 📌 Allow omitting doxygen when type and variable name is enough Active for a followup.

@larowlan, thanks.
I like examples, so I expanded on suggestion.

quietone → credited alexpott → .

quietone → credited catch → .

quietone → credited longwave → .

quietone → credited Spokje → .

Closed #3291517: [policy, no patch] Use type declarations for new class properties → as a duplicate. I am adding credit.

+1 Feels like we are embracing PHP conventions.

+1

This has been standard practice in our client code for ages. +1

+1, yes please!

Remove duplicate <code> from proposed res

1. s/type hint/strict type definition/?
2. Should the new text say that strict types are preferred wherever possible?

IMHO the examples should be more generic. The $dbh property is long gone from the Database API and regadless of that it was a very special case being a PDO related property.

🙏 Yes, please! Far less boilerplate 👍

+1

Updated the wording taking into account the suggestions from #28 and #29. Switched from a public property to a protected one. Used the EntityTypeManagerInterface since this is very recognizable, and uses the interface as a type which is the best practice.

I agree with this as it stands, but it seems worth noting that 📌 Use PHP 8 constructor property promotion for existing code Needs work means that any property promoted via a contructor won't be defined separately at all, so the entire statement goes in that case. That makes me wonder how many strictly typed properties will be left to document once that issue lands.

I think we missed a step, according the current process this needs to have a working patch to test the change.

All changes that can be tested with coder/phpcs. A working patch is to be provided with the issue. Committers will test the phpcs rule as part of the approval process.

And what happens to the existing sniff, currently excluded, <exclude name="Drupal.Commenting.VariableComment.Missing"/>

If we follow the new proposal at #3365085: Update the coding standards process on the project page → then based on the current situation, we should have checked the existing sniff (which you just have), but we're not blocked on a new one.

Since <exclude name="Drupal.Commenting.VariableComment.Missing"/> is already disabled and therefore changing the rule won't break core's existing enabled ruleset.

That would get us to:

If there is no existing phpcs rule for the change, then optionally a patch can be provided on the coding standards issue to implement the rule. Once the coding standards issue is fixed, an issue can be opened either against phpcs or coder to add support for the rule. This is to prevent issues being opened against coder/phpcs for rules which core might not adopt.

in the new process.

i.e. we should open an issue against coder asking for either a new sniff, or a modification to <exclude name="Drupal.Commenting.VariableComment.Missing"/>, as part of the process of marking this issue fixed.

Based on that, moving back to RTBC.

I have updated the documentation.

Confirmed the changes in the documentation. This can be marked as fixed.

Fixing credits:

Kingdutch: made issue, discussed in slack.
quietone: managing this the last few months, and driving discussion.
larowlan: heping out with issue management and discussion
chx: discussion, and followup work.
bbrala: discussions and issue management
pfrenssen: work on docs
dww: work on docs

Marking as fixed. Lovely to see a codingstandards issue fixed. <3

Thanks everyone.

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

Did we ever create a follow-up for converting existing code? It's hard to enforce this policy when consistency matters.

Probably not, just make one?

Created a child: 📌 Remove @var for strictly typed class properties Active