10000 Yet another attempt for consistent variable naming ;-) by ThomasLandauer · Pull Request #17134 · symfony/symfony-docs · GitHub
[go: up one dir, main page]

Skip to content

Yet another attempt for consistent variable naming ;-) #17134

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

Closed
wants to merge 1 commit into from

Conversation

ThomasLandauer
Copy link
Contributor

Following the convention you showed me in #16560, the variable's name here should be $config ;-)

So I'm suggesting: Always use the full class name as variable name (in config files): $containerConfigurator, $frameworkConfig, $securityConfig, etc.

Following the convention you showed me in symfony#16560, the variable's name here should be `$config`.
**So I'm suggesting: Use the full class name as variable name everywhere in config**: `$containerConfigurator`, `$frameworkConfig`, `$securityConfig`, etc.
@carsonbot carsonbot added this to the 5.4 milestone Aug 9, 2022
@javiereguiluz
Copy link
Member
javiereguiluz commented Aug 10, 2022

I'm not sure I follow your reasoning. We use $framework in similar examples everywhere the docs:

Searching 659 files for "function (FrameworkConfig $framework)"
107 matches across 37 files

Searching 659 files for "function (FrameworkConfig $frameworkConfig)"
0 matches

Also, what we do in the docs for examples like #16560 and this PR is:

  • XxxConfigurator class -> $configurator variable
  • XxxConfig class -> $xxx variable

Personally I'm fan of long variable names, but in this case I think it makes sense to make the code more readable by removing the prefix before Configurator and the Config suffix.

Of course we can discuss about changing this practice (nothing is immutable in Symfony Docs) but given the burden for maintainers, any big impact change like this must be much better than the previous situation, to justify the effort of updating everything, dealing with merge conflicts, etc.

That's why I'm closing this without merging, but I hope you understand the given reasons. Thanks.

@ThomasLandauer
Copy link
Contributor Author

@javiereguiluz In #16560 (comment) you told me the exact opposite!

Here you're saying:

XxxConfigurator class -> $xxx variable

There you said:

The argument name [for ContainerConfigurator] used in the docs is $configurator instead of $container.

@ThomasLandauer ThomasLandauer deleted the patch-11 branch August 10, 2022 15:21
@javiereguiluz
Copy link
Member

@ThomasLandauer sorry! I've just reworded my previous message a bit. What I wanted to say was that I think it's OK in these two (different but related) cases to not use the full-length variable names to make code examples a bit more readable.

@ThomasLandauer
Copy link
Contributor Author

@javiereguiluz What I mean is if you don't want to use the full name, then you should always use either the first or the second part. Right now, it's sometimes the first, sometimes the second - based on a subtle difference that nobody notices ;-)

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

Footer

© 2025 GitHub, Inc.
0