Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use fully qualified names in inline code #100

Closed
wants to merge 2 commits into from

Conversation

dingo-d
Copy link
Member

@dingo-d dingo-d commented Aug 12, 2022

This PR depends on #98. Once that is merged, this PR should be rebased to the master branch.

The PR adds rules about the fully qualified names in the inline code and is the continuation of the additions of 'modern' PHP code in the WordPress PHP Coding Standards handbook based on the make post by Juliette Reinders Folmer.

@dingo-d dingo-d self-assigned this Aug 12, 2022
@dingo-d dingo-d mentioned this pull request Aug 12, 2022
@dingo-d dingo-d force-pushed the use-fully-qualified-names-in-inline-code branch 3 times, most recently from cfb9817 to 31f5601 Compare August 20, 2022 12:19
Copy link
Member

@jrfnl jrfnl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this needs to be added to the manual. As of PHP 8.0, using whitespace or comments within the name is a parse error (remember: the Make post was written well before PHP 8.0 was released).

wordpress-coding-standards/php.md Outdated Show resolved Hide resolved
@dingo-d dingo-d force-pushed the use-fully-qualified-names-in-inline-code branch from 31f5601 to 0f49b18 Compare August 24, 2022 03:04
@dingo-d
Copy link
Member Author

dingo-d commented Aug 24, 2022

I'm not sure this needs to be added to the manual. As of PHP 8.0, using whitespace or comments within the name is a parse error (remember: the Make post was written well before PHP 8.0 was released).

I can add it as a note below, would be a good addition IMO 👍🏼

@dingo-d dingo-d marked this pull request as ready for review August 24, 2022 03:08
@dingo-d dingo-d requested a review from jrfnl August 24, 2022 03:08
Copy link
Member

@jrfnl jrfnl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While the note about PHP 8.0 does help, I still don't think this section needs to be in the manual.

Code shouldn't cause parse errors on any of the supported PHP versions, Doesn't matter the reason of the parse error.

That's not something which is a coding standard, that's something which is a basic necessity for the code to be able to run.

@dingo-d
Copy link
Member Author

dingo-d commented Aug 24, 2022

Oh, you meant we should drop this all together? I just added all the rules we had in the spreadsheet 😂

But your reasoning makes complete sense. I'll close this PR 👍🏼

@dingo-d dingo-d closed this Aug 24, 2022
@jrfnl
Copy link
Member

jrfnl commented Aug 24, 2022

Yes, sorry if my original remark wasn't clear enough.

@GaryJones
Copy link
Member

Was there any proposal about when to use inline FQCN vs an import?

@jrfnl
Copy link
Member

jrfnl commented Aug 24, 2022

There was not. At the time, we decided that as WP isn't using namespaces/import use statements, it was not up to WP to set a guideline/standard for when to use FCNs vs import statements.

I know of at least one company in the WP sphere where they strictly enforce always importing classes, but forbid importing global functions/constants and instead enforce using FQNs for those. For namespaced functions/constants, the namespace is imported, and the functions/constants use partially qualified names.

Both Slevomat as well as PHPCSExtra have various sniffs which could enforce one or the other, so userland has a choice here (and the means to enforce their choice).

@dingo-d dingo-d deleted the use-fully-qualified-names-in-inline-code branch August 26, 2022 09:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants